Architecture
The 3 C’s of Architecture was introduced: Connection, Cohesion, and Changeability.
You can read about the 3 C’s of Architecture here: http://blog.xebia.com/2010/04/23/the-three-cs-of-architecture/
But here’s my spin:
On first glance, it is not really obvious what is meant by connection. What is meant is: connection to organizational goals. Architecture should be aligned to organizational and business goals and add value by facilitating the achievement of these goals.
Another word for Cohesion is Consistency. I often look for consistency in architecture, software, documents, etc. Consistency is standardization that pays off because it reduces the effort in understanding the architecture, software, documents, thereby reducing time and costs when implementing further changes.
Modern wisdom says that we should architect for change, because “change is the only constant”. For me, the raison d’etre of architecture is to manage complexity thereby ensuring changeability and minimizing the cost of future changes. This is because by definition, software is complex, but the complexity can be managed.

Lean Principles
The Lean Principles that were introduced are:
1) Base management decisions on long term philosophy, even at the expense of short term financial goals
2) Create a continuous process flow to bring problems to the surface
3) Use “pull” systems to avoid overproduction
4) Build a culture of stopping to fix problems to get quality right the first time
5) Use visual control so no problems are hidden
6) Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others
7) Go and see for yourself to thoroughly understand the situation
8) Make decisions slowly by consensus thoroughly considering all options, and implement decisions rapidly
9) Become a learning organization through relentless reflection and continuous improvement

The above principles can be further distilled into 3 quick-win actions:
1) Make work visible
2) Limit work in progress
3) Make work flow
#1 is a quick-win that I have employed and continue to employ. For example, it’s amazing how a continuous integration tool can do to focus the team, and give a pulse on progress.
#2 and #3 are closely related. What we know is that flow is more important than resource optimization. Ensuring the flow by making sure that intermediate products do not pile up often result in faster delivery than if all resources continue to produce at 100% capacity despite the fact that the next person/team in line is not ready. This is counter-intuitive for traditional project management, which is still very prevalent in most large organizations, and it is up to us to teach the concept of flow and other lean principles.

Other resources on lean principles that I have found useful are:
- http://agilesoftwaredevelopment.com/leanprinciples
- http://www.leansoftwareinstitute.com/art_ilsd.php

Principles distill best practices into simple concepts that help us focus on what we need to do. Often, we all know the concepts, but the hard part is the implementation. By putting “abstract” lean principles into the context of architecture, it helps to visualize what needs to be done and brings us one step closer to applying the principles in our specific situations.

Lean Architecture Principles
“Lean Architecture enforces value creation by balancing business and technical values/priorities and converging focus of all stakeholders to required actions at the right time and at the right level of details.”

The Lean Architecture Principles that were introduced are:
1) Architecture initiated by business goals
2) Architecture emerging from projects
3) Incremental development of architecture
4) Focus on (business) value stream
5) Travel light
6) Just in time, just enough
7) Think big, act small
8) All hands on deck early on
9) Always involved
10) Comprehensible over comprehensiveness
11) Freedom where possible, standard where needed

Each principle is further elaborated in the Xebia blog here: http://blog.xebia.com/category/lean-architecture/

Architectural Challenges
Later, we broke into groups to discuss which Lean Architecture Principles can be applied to solve one of the architectural challenges that we came up with. We chose to discuss the challenge of determining how far we should look for architecture. 3 years? 5 years? 10 years?

My first comment is that it’s not about time. It’s about creating a vision and then creating a roadmap (Think big, act small) towards that vision. The time is only an estimate of how long it would take us to get to the vision, which is not really that relevant since architectural improvement should be a continuous process (Incremental development of architecture) and each step is measured for business value. Many of us work in organizations where there is a fair amount of legacy system. When designing from scratch, we know that we should design loosely coupled, flexible systems, but what do we do with systems that are already there? One solution is to create a backlog of architecture changes/refactorings and wait for the chance to include them into project backlogs when the time comes. The architecture backlog should be communicated widely so there will be no surprise.
An insight from Theo Maas of KLM is: “Architecture must mirror your business processes. Even when the organizational structure changes, the business processes often stay the same.”
I would go one step further to say that lean principles can be applied to the business processes themselves to eliminate waste.Companies that dare to improve their processes can benefit from reduced costs and increased productivity in their day-to-day operations. When this is done with business and IT in close collaboration, IT can add value by supporting the new (more efficient) processes.

Bol.com: Service Discovery Workshop
Serge Beaumont shared with us his experience at Bol.com, where he started to run Service Discovery Workshops with full participation from +/- 20 people from all departments and functions who got together to discuss architecture and initiate architectural changes (All hands on deck early on). The goal was to create an architecture that would keep them in business until 2013. I think it is brilliant that people at Bol.com have the foresight to make the effort early on and collaborate on architecture. A simple model was followed to structure the workshop:
1) Domain Objects – Identify and validate (throw out invalid/obsolete ones) domain objects. Identify partitions and cluster closely related stuff. Domain objects can be in one domain only – that helps to remove duplication.
2) Processes – Identify and validate processes.
3) Services – Identify the services needed to execute the processes.
4) Messages – Identify what the services require to do their work

Conclusion
This seminar has inspired me to refocus my efforts on initiating architectural improvements at my current place of work. I’m glad to have had the opportunity to discuss with fellow architects the common challenges and solutions for initiating architectural changes in organizations. This has confirmed for me what I have known all along and have been doing for awhile, which is that architecture includes both content knowledge as well as process knowledge, and where success is contingent on the ability to initiate and lead changes in both. As with many good ideas, the concepts are simple, but the implementation is hard. I hope that doing my part to spread the word on what we know as a community will help others to improve architecture in their companies.

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

Scrum Butt
Shock Therapy was introduced because most teams that think they are doing Scrum are actually only doing Scrum Butt – “We are doing Scrum, but we don’t do all of Scrum for some reason or another”. Perhaps there are good reasons for excluding some parts of Scrum, but without truly understanding the reason behind a Scrum practice or the implications of skipping it, agile teams struggle to become hyper-productive, or mistakenly, struggle with Scrum itself.

Nokia Test and Statistics
In 2005, Bas Vodde developed a test for Nokia to quickly assess the status of a team that claims to be doing agile. In 2008, Jeff Sutherland extended this test with multiple choice answers and a scoring system. This resulted in the Nokia Test. Although it does not cover all of Scrum or all best practices often used with Scrum (such as XP practices), it aims to save teams from the common dysfunctions of a Scrum team.

The Nokia Test is separated into 2 parts: the first to deal with iterative development and the second to deal more specifically with Scrum. The gist of the questions are as follows:

Part I Are you doing iterative development?
1. Are your sprints timeboxed to 4 weeks or less?
2. Are your software features tested and working at the end of each iteration?
3. Do you start with agile specifications (user stories, just-in-time specs)?

Part II Are you doing Scrum?
4. Do you know who your product owner is?
5. Do you have a product backlog prioritized by business value?
6. Is your product backlog estimated by the team (i.e.people who do the work)?
7. Does your team generate burndown charts and know its velocity?
8. Is the team’s work free from disruption by project managers (or anyone else)?

Of the above, only 50% of teams claiming to be agile pass Part I and only 10% pass Part II. These are world-wide statistics.

Take the Nokia Test yourself here.

Introducing Shock Therapy
Teams starting with Scrum often come across similar challenges or pitfalls that prevent them from benefiting fully from Scrum. In the past, it would take 2 years for a company to achieve 300% improvement. Some teams never figure it out. Shock Therapy has consistently led teams to 300% increase in productivity in 6-8 weeks.

Shock Therapy is:

Jeff Sutherland compared Shock Therapy to martial arts training. You enter the dojo and do what the Sensei (teacher) says. You repeat exercises over and over until it is part of muscle memory. Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others.

Because Scrum, as a framework, is flexible and customizable to a company’s own practices, teams starting with Scrum often have too many choices and don’t know how to make decisions. We don’t expect customers to know what they really want until they have seen a prototype, so why do we expect Scrum teams to know exactly what they want before seeing a prototype? Shock Therapy is the prototype.

Case Study: Scott Downey as Scrum Sensei at MySpace

• To take teams to hyper-productivity (>240%), on average took 2.9 days per team member where the team includes Scrum Master and Product Owner
• Rules stay in place until 1) the team starts to go hyper-productive 2) the team completed 3 successful sprints 3) have shown a good business reason to change the rules
• Rules are:
  • Everyone attends Scrum training before starting first sprint.
  • Sprints are 1 week long.
• Scrum Sensei’s Definition of Done (DoD ensures quality as a balance to speed) is introduced after basic success:
• Feature Complete
• Code Complete
• No Known Defects
• Approved by Product Owner
• Production Ready
• Estimates are in Story Points
• Scrum Sensei controls Scrum board until team is ready
• Condensed Sprint Review, Retrospective, and Sprint Planning into one 4 hour meeting per week. Over time, the team needs less time and will move down to 90 minutes.
• Incomplete user stories are rejected before the Sprint
• Multitasking is forbidden: context-switching takes extra time and slow things down.
• Scrum Sensei gets respect by removing the team’s worst impediment within a few days.
• On average, after 6-12 weeks, teams are functioning at above 500%. (Scott Downey)
• One team was at 1,650% after 16 one-week sprints
• Teams usually start out resisting the Shock Therapy. After a few weeks, they are indifferent. “Then they scream bloody murder if I try to take Scott away from them.”

In Perspective: The Big Picture
In terms of organizational changes, bottom-up (participatory) changes tend to take longer to take root, but also tend to have more long lasting results. In contrast, top-down (directive) changes may have quicker results, but are harder to get ingrained into the organization (especially when measurement of change is not in place). Real organizational change need to be participatory, with strong leadership supporting the changes along the way.

I see Shock Therapy as a combination of top-down directive and participatory change. Starting with a top-down directive, backed by management who understands Scrum, teams are able to participate in the introduction of Scrum. Most skeptics reject Scrum practices because they cannot understand the benefits without experiencing them. These skeptics often are convinced after some smell of success. Experience show that Scrum teams introduced to Scrum in this way reach hyper-productive quicker and tend to continue the trend of improvement after the Scrum Sensei is gone.

• Even if you don’t believe the numbers, can you really afford to ignore the possibility that they are real?
• What would it mean for your business if you are able to reduce time-to-market of new funtionality to a matter of weeks rather than months or even years?
• What would it mean for your business if your competitors achieve this time-to-market reduction?

– Albert Einstein

Posted using ShareThis

• 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.

Here are some highlights from Devoxx 2008:

Java 7
In a keynote, Mark Reinhold gave a summary of the changes in the JDK for Java 7. Here is a good summary by a fellow Devoxx attendee. The main idea I got from this is the work started by Doug Lea with JSR-166 to introduce a light-weight concurrency framework into Java with the intention to take advantage of the increasing availability of multi-core processors. This has been in the working since Java 5, but is finally coming to light.

Smart = Agile++
Smart = Agile++

• rich internet applications
• concurrency
• agile
• scripting languages

For more info on continuous integration, read it from Martin Fowler:
Continuous Integration by Martin Fowler

 Loading …