Gero Vermaas

How architecture enables kick ass teams (1): replication considered harmful?

Gero Vermaas

At Xebia we regularly have discussions regarding Agile Architecture? What is it? What does it take? How should you organise this? Is it technical or organisational? And much more questions… which I won’t be answering today. What I will do today is kick off a blog series covering subjects that are often part of these heated debates. In general what we strive for with Agile Architecture is an architecture that enables the organisation to keep moving fast and without IT be a limiting factor for realising changes. As you read this series you’ll start noticing one theme coming back over and over again: Autonomy. Sometimes we’ll be focussing on the architecture of systems, sometimes on the architecture of the organisation or teams, but autonomy is the overarching theme. And if you’re familiar with Conways Law it should be no surprise that there is a strong correlation between team and system structure. Having a structure of teams  that is completely different from your system landscape causes friction. We are convinced that striving for optimal team and system autonomy will lead to an organisation which is able to quickly adapt and respond to changes.

The first subject is replication of data, this is more a systems (landscape) issue and less of an organisational issue and definitely not the only one, more posts will follow.

 Read more

Can continuous delivery succeed without management support?

Gero Vermaas

Last wednesday the first meetup of the Continuous Delivery Think Tank was held at Xebia offices in Hilversum. The goal of the Think Tank is to gather people that want to implement continuous delivery in their organisation, to help each other using the collective brainpower of the group. In this first session we explored what the first steps should be when you want to successfully introduce continuous delivery into your organisation. The level of experience varied widely across the participants (from doing 1000s of deployments per day to just starting to explore the possibilities), so there was something to learn and share for everybody. This lead to lively discussion and by using the 6 Thinking Hats method we ensured that   the question was approached from different viewpoints. The conclusion was that trust and cooperation are key and although this can start small, it does have to spread across the organisation to be really successful.

 Read more

3-2-1 Bang! Summary of first Software Architecture Pressure Cooker meetup

Gero Vermaas

Last Thursday the first Software Architecture Pressure Cooker meetup was held. The goal of these meetups is to exchange experiences on software architecture. This is done by working on a real life case using the following format:

  1. A specific challenging scenario is introduced in general terms
  2. An organization is invited to present a real life case that matches the scenario introduced, they act as product owner during the evening.
  3. In a couple of rounds the group brainstorms, breaks up in sub groups and works on solutions.
  4. All solutions are presented to the product owner
  5. Some heated discussions take place between the various subgroups where each group tries to convince the other groups.

The scenario for this first meetup was "3-2-1 Bang!". Characteristics of this scenario are:
 Read more

Did we make the right architectural choice?

Gero Vermaas

That was the question on my mind while walking out of an hour and a half meeting which was attended by 6 people. The problem wasn't that complicated, we went into the meeting with 3 alternative solutions: so why did it take so long to pick one? It kept nagging me a bit and then I recalled the "Simple Architectures for Complex Enterprises" book by Roger Sessions. By applying his approach I was able to determine if we made the right choice and I'll describe the results below.

 Read more

Customize off the shelf, be warned

Gero Vermaas

A while ago I realized that the C in COTS stands for Customize, so in reality it is Customize Off The Shelf (and not Commercial Off The Shelf). The premise of COTS products is that it reduces system development costs and long term operational maintenance costs. Sounds like music to management and procurement departments. Reality can be different. Realizing that the C stands for Customize highlights one of the pitfalls most people are aware of: the amount of customization needed to make a COTS product fit in an organization can be huge. But there are more pitfalls and in this blog I'll highlight a few.

 Read more

Filling the backpack

Gero Vermaas

At the start of your career your backpack with is filled with lots of theory and as your career progresses more and more experience get's thrown in, perfect. At some point you won't be learning new things if you keep doing the same role. That's why people take up different roles and grow in a team. However, the goal of the team's you're in often remains similar: develop system X that realizes user stories Y and Z. Many people do lots of roles, but all on the 'producing' side of the IT. I personally experienced the value of jumping to (one of) the other side(s) for a period of time. After returning to my original role I became much more effective.

 Read more

Lean Architecture Principle #10: Architecture emerging from Projects

Gero Vermaas

This is the tenth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The tenth principle we discuss is called "Architecture emerging from Projects". Read more

Lean Architecture Principle #7: Architecture Initiated by Business Goals

Gero Vermaas

This is the seventh post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The seventh principle we discuss is called "Architecture Initiated by Business Goals". Read more

Lean Architecture Principle #4: All Hands on Deck early on

Gero Vermaas

This is the forth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The forth principle is call "All hands on deck early on" (initially coined  by James O. Coplien). The essence of this principle is that all stakeholders of a project are involved at the start of the project.

 Read more

Lean Architecture Principle #1: Always involved

Gero Vermaas
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called "Always Involved". The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.
<!-- MORE -->
We probably all know at least one example of architects that were not connected to the business objectives or to the projects being executed in an organization. The architects get an assignment from a project manager, isolate themselfes in an office, works for months discussing with each other, but not with business, project, operational maintenance or other stakeholders and produce a 100+ page document containing their perfect architecture. After delivering the document they abandon the ship and await a new assignment. This is an extreme case (although it does happen in reality), but variations in which the architect is only involved at the start of a project, or only communicates with one of the stakeholders are very common.
Always involved means that architects are involved during the whole lifecycle of a project, from the initial inception of ideas up until (and including) when the deliverables of a project are in production. The degree of involvement may vary depending on the project phase, but architects always stay in the loop. The architects feel responsible for the business goals and are committed to deliver value such that these goals are reached. They are supporting multiple projects and constantly create alignment between stakeholders of all projects and takes lessons learned in projects into account, ensuring that other can learn from it.
How does the principle contribute to the 3 C's of architecture? A better cohesion is achieved since the architect takes an active role in all projects. This enables him to ensure that projects learn from each other and that similar problems are solved in a consistent way (e.g. process orchestration). Connection with organizational goals (both business and project) is improved since architects interact with the business and project side on a regular basis. This forces architects to understand these goals and enables him to translate these into IT goals. Architects also ensure that the other stakeholders understand the reasoning for these IT goals. Also, due to the constant involvement in projects, feedback, lessons learned, are immediately incorporated in the architecture vision. Changeability is improved because architects know what parts of the business are most likely to change, he can - together with other stakeholders - make decisions that are facilitating this change or at minimum not creating upfront barriers that would make responding to these changes hard.
What does it bring the organizations when the architects are always involved? First: The priorities are set correct. Both from business and project side architects are fed with priorities and they can now make a balanced decision: on what should they focus now? Impediments that prevent (or shortly will) projects from making progress are on the architects radar. So are the latest market or organizational developments from the business side. Because the architects are constantly fed with information from all stakeholders and results of choices made earlier by themself, subsequent decisions will be based on real world facts/experience and not on theoretical assumptions.
This was the second in a series of blog posts on Lean Architecture principles, the next one will follow in about a week.

This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The first principle that we discuss applies to the architect role and is called "Always Involved". The architect role is not limited to one project phase or even one project, a good architect takes a much broader perspective. The Lean Architect constantly communicates with all stakeholders (from business till operations), plays an active role in running projects, and ensures that lessons learned in projects are known and where applicable used in other projects.

 Read more