Duchess
Globally Connecting Women in Java Technology

The Zone—San Francisco’s Hotel Nikko, Hilton San Francisco, and Parc 55 hotels and the surrounding area—will be dedicated to developers during the week of JavaOne and Oracle Develop.

Unparalleled education and practical hands-on sessions, engaging activities, exceptional entertainment, and food and drink in the Zone will be exclusively geared toward the developer community converging at the two conferences. Network, share information, and learn from leading experts in the Java, PL/SQL, rich internet application development, SOA communities, and more.

Discount may have been arranged by your local JUG. Check with your local JUG.

Java2Days conference is premier event in Eastern Europe to present the latest trends in Java development in the following areas:

• Core Java Platform & Desktop
• Enterprise Java
• Java & the Cloud
• Java Web Technologies and Rich User Experience
• Java for Mobile and Devices

The second Java2Days will be held at the Inter Expo Center on 8-9 October, 2010, in Sofia, Bulgaria.

The conference is the first of its kind to be held in Eastern Europe, focused to highlight today’s cutting edge trends in building software applications with Java development tools.

Over two days, more than 600 attendees will meet world famous lecturers, engaged all year round in such events as JavaOne, The ServerSide Java Symposium, Jazoon showcasing their latest knowledge in creating more reliable, scalable and secure solutions using Java technologies in more than 20 technical sessions.

The major purpose of the event is to become a place for passionate Java developers to get in touch with the latest technologies, to become a significant part of the global Java community and to learn from the best.

For Duchess members, we have received a generous offer from the conference organizers: 10 free conference passes (Economy Pass) for each invited official Java User Group and 40% discount of every next pass.

If you want to go, get in touch.

XP Day Benelux is an international conference about Agile methods, intended for people from all walks of life who are involved with IT. It provides a good opportunity for exchanging ideas and sharing experiences and is suited for both experienced participants and beginners in Agile methods. The focus of this conference is on practical knowledge, real-world experience, and active participation of everyone.

The 8th edition XP Days will also be held in Kapellerput in Heeze, near Eindhoven.

Call for Sessions is now open (until July 15)

We’ve applied for a Duchess BOF at Devoxx 2010. Come join us so we can meet each other and find out what has been going on in the Duchess community and how you can get involved.

Yesterday, I attended a lean architecture seminar given by Xebia. Gerard Janssen, Gero Vermaas, Sander van den Berg, and Denis Koelewijn did a good job in putting together the seminar and taking us through an introduction of Lean Principles and then applied to architecture to become Lean Architecture Prinicples. During the seminar, we discussed architectural challenges and also learned how architecture was done at Bol.com as presented by Serge Beaumont. I left the session re-inspired on how to approach architecture improvements at my current place of work.

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.