Agile Architecture in 10 Steps

In my latest ten years, working as an IT consultant in the area of enterprise architecture, I got more and more questions about combination of the agile software engineering (not just only development) and the enterprise architecture which comprises business and software architecture.

Especially for the big organizations it is a challenging topic due to their internal culture and structure that doesn't really suit to the values and principles of "being agile" as defined by the Agile Manifesto. The main idea of the agile software engineering, besides the responsive, incremental and iterative development process, is to work in a *vertical* and not *horizontal* way. Only *vertical work*, defined e.g. in a form of a user story, can deliver business value as expected by the stakeholders. However this 90 degree turn in the way you work is the biggest problem especially in case of a big organization. It requires involvement of much more departments that work together *in parallel* comparing to the classical *horizontal work* with defined layers and responsibilities. This *vertical work* simply drill down your whole system thus affect many areas, especially architecture, which in this context has also *to be agile*, means that you have to think about agile architecture as a process of building a software system as well as a structure of it.

You can find plenty books about architecture. Most of them describe *what* architecture is and *why* you should architect it (yes, it sounds a little bit strange but you actually *architect architecture*). However there are just few books that say *how* to do it. That is exactly what this presentation and my upcoming book is about. This “HOW to architect agile architecture”, based on my experience and examples from my current project where I work as a lead architect in one of the biggest insurance companies in Germany.


Thinking "Beautiful" or "Agile" when Architecting Architecture

Working as the lead architect in my current project I decided to choose agile way of designing architecture. I decided to let architecture grow with the project. I decided to choose pragmatic approach making (as far as possible) architectural decisions that suit to the needs of the project. Decisions that align engineering benefits with the costs, thus reduce risks. And it works.

However focusing on the topics mentioned above causes admittedly the architecture to be agile (risk-driven, pragmatic etc.) but does not guarantee that the resulting architecture will be simply beautiful.

It is like designing a perfect house to live in, but possibly ugly when you look at it. And most probably a beautiful house will be more expensive as the "pragmatic" one, being however more attractive to the residents. Quite interesting trade-off that in my opinion should not be forgotten in case of a software architecture.

A perfect software architecture is agile and beautiful as well.


Agile Culture Capability Model or Can We All Be Agile in the “Same Way”?

Slides from my talk at Coding Serbia 2014 are online...


Offshore, nearshore, outsourcing? “No, I don’t want that, not once again” many IT managers would say… and not without a reason. Plenty of enterprises have already run classical, waterfall projects with the mix of onsite and nearshore or offshore teams. Unfortunately most of them have ended without success. Quite fast a question may arise whether the used methodology was an appropriate one. The hype of the agile project management has created a naive hope that finally the nearshore and offshore projects can be executed successfully. “Agile is the cure!”.

Unfortunately, this naive believe proved to be wrong, and quite often the achieved results of these projects were similarly bad or even worse comparing them to the classical approach. An agile project, when run onsite, delivers much better results than a similar waterfall project. However we have observed many problems with the effectiveness and efficiency of agile projects if they were run in the combination with nearshore or offshore teams. These problems were clearly associated with the cultural differences between the teams. Interestingly, this negative influence of the cultural differences was definite stronger on agile projects comparing to the waterfall projects… Do other cultural standards than our western ones hamper the acceptance of the agile values and principles? Is the agility something basically western? Can we measure an “agile capability” of a team or individual?

This session focused on the "Agile Culture Capability Model" (ACCM) that allows delivering answers to these questions. The ACCM model is based on the proven literature about cultural standards and the personal experience collected by the author during his professional career as an IT-Consultant.

The author of this talk is Pole who lives and works for many years in Germany together with his Brazilian wife. He has led successfully many agile projects in Germany with the nearshore (Poland, Romania) and offshore (Japan, China, India) teams. He hopes that he ACCM can help you to be successful as well.


Agile Architecture: Real World Problems, Abstractions and Generalizations

When designing architecture you have to be aware of the temptation to go into direction what I call generalizations.

As a real world problem we want to solve with an architecture is a not trivial one, we use abstractions (in form of the models) to describe it. Having this abstract problem modeled, we develop a solution, which is an abstract solution as it solves an abstract problem. After that we apply this abstract solution to the real world to get a real world solution to the real world problem we encounter at the start. This way of architectural work has been defined by Mary Shaw and depicted by George Fairbanks in his book as follows:


The First Law of Predictable Business (5th Anniversary)

Exactly five years ago I have published my first blog about predictable business. I'm a little bit sad that I haven't found until now much resonance on this way of thinking, however this time will come, I'm sure.

So let's repeat here the thoughts from 2009:

Before I start to build the model of predictable business, I have to clearly define the term of predictability. What does it mean, that I can predict a certain event? Taken from real life, I would say, I know it will occur in the future. So to predict is to know.

As stated in Wikipedia predictability is the degree to which a correct prediction or forecast of a system’s state can be made either qualitatively or quantitatively.

The second term that requires explanation is “business”. In my context I define business from the process point of view. So to do business means to follow a certain process definition, to be a part of certain process instance. Every process contains activities and transitions between them. In a well defined process I know from the beginning conditions which are responsible for a certain flow of the process (transition from a-activity to b-activity). Such process have no uncertainty e.g. are predictable.
The first law of predictable business:

If there is no uncertainty in a process the business predictability achieves its maximum 

(simply saying: business is predictable in 100%).
This law is based on entropy in information technology (also known as the Shannon entropy) which states: if probability p of a discrete random variable x (in my case, the flow of a process) is p(x) = 1 than its entropy N equals to null:

But in the real life the transitions between activities are not defined as simple rules. We have to talk about probability of a transition between activities that is less than 1 (one).