Today, a friend of mine asked me this question. We both know how companies usually make architectural decisions, but how Agile teams (should) make significant architectural decisions is less obvious. A difficulty with this question is that answer has many perspectives: one could talk about business need, technology choices, documentation, who is involved in decision making, how they actually do it, what kind of meetings, etc.
Today, many software product vendors have placed word Agile in front of the original name of their platform. If this is a proper use or misuse of word Agile, is up to you. The discussion about it might be useful, but I’m interested more in how good each of the platforms support Agile values. For anyone to assess this, a set of principles is needed. These principles can be used by Agile teams to better decide if a certain platform will help achieve your goals or stand in your way. So let’s start:
1. It is the team that makes architectural decisions. A platform should be capable of fulfilling these decisions.
Many platforms have so called out-of-box architecture. It means that significant decisions are already made and defined by the platform. In this context, significant decision means any decision which strongly influences the structure and look of the solution. I am not talking about the commodities like messaging systems, application server platform, database, and so on. There is a certain, hard to define, line between what is a commodity and what not. The significant decision here is still wether you want to use certain commodity platform / component or not. But, you almost never want to mess with inner workings of such components. Directly, they have little to do with your business problem domain. This is often not the case for things like BPM tools and ERP platforms. Why not? They tend to intrude the space of the only people who are really capable of fulfilling the business need, which are Agile teams themselves. Signs of this problem is when platform has very specific ways in which certain business requirements are solved or no capability at all. Let’s say: if you want to do payment on your website, then you must use a specific module for these credit cards.
2. If you first need to spend time on implementing some kind of baseline without direct value for business, then it ain’t Agile.
Welcome to 21st century where you still have vendors who try to convince you that you need to be patient for half a year or a year. You spend 500.000 euros before seeing a failure, because of your own fault. “You shouldn’t have changed your requirements!” or “You should have known your requirements before you started!” – says the vendor in a court. Forget the promises, if your team is not capable of delivering value in production in one sprint, then the platform does not belong in this century.
3. Is a platform capable of delivering in production continuously?
I must admit, although I do know how difficult can be to properly deliver things in production, I almost get convinced by those sales presentations where things look like magic. A few hard questions later and this magical stuff proves to be nothing more than hot air. Until your team actually experiences and exactly knows how to deliver solution every couple of weeks (preferably after every check-in) with little effort and high quality, don’t trust those nice looking PPT pictures.
4. Craftsmen deliver value, not platforms
First statement on a typical vendor site begins something like this: “With our software you will reduce costs, speed time to profit, get real time visibility,…” and so on. I should make a software to produce these generic statements, so all these vendors can reduce their costs. 🙂 It sounds like a good business case. Anyway, no software implements itself. Even a rollout of MS Office can become a mess if you don’t have craftsmen knowing their stuff. In other words, no software platform ever delivers business value. It is the people who actually know how to use this technology in specific context. As a customer, if you want to be Agile, you should spend more time on hiring great craftsmen, and less on which platform is the correct one. This should be the job of the hired craftsmen and not yours. In that way, your team might fail to produce value and be held accountable. Blaming a platform, never really works out in customer’s favour. Specially if vendor behind it is one of the largest ones.
5. The team should be able to refactor most of the previously made decisions and implementations?
If anyone advise you to make many difficult and important design decisions before starting delivery, because otherwise you will get in trouble later on, then your platform is not Agile. If business changes their mind, the platform should not be the bottleneck. Again, it is the 21st century, and you don’t want to say No to your customer and users because of the platform.
6. Can you automate testing?
One of the main reasons why Agile teams are capable of delivering every couple of weeks or even more frequent, and still maintain high quality, is because of test automation. TDD, BDD are few of these amazing practices that improved quality of our solutions tremendously. If you cannot automate the validation of everything before every delivery, then your platform is definitely not Agile.
7. Last but not least, if your craftsmen don’t like the platform, don’t use it.
It is very disturbing to hear people treat developers like some children who get bored with their toys. Although many developers lack skill to properly argument their dislike of certain technology, there is always a truth in what they are telling.
I was usually the guy who facilitated different architecture related sessions at HaMIS – Port of Rotterdam. As soon as I was absent for few weeks, nobody organised them in those weeks. During retrospective meeting, several of them would mention they missed those meetings and blamed themselves that nobody thought or took responsibility for organising them. The simple conclusion and reason for this problem was: Viktor usually organised them, and he is the architect.
Every now and then I get in discussion with people about different roles we have in software development. For example, it starts with explanation that Scrum needs someone to be responsible for architecture. That role is named e.g. “Architecture Owner”. Then I try to explain that from Agile perspective, we would like to have whole team feel responsible for the architecture. Having one guy call himself architecture owner, tester, analyst will clearly contradict this goal. The answer is then: Oh no, there is no problem at all. We just need to have architecture role and it does not need to be one person. It can certainly be fulfilled by whole team.
Theoretically, it is possible to have multiple people fulfilling one role. The interesting thing is that nobody really does something like that in reality. It is just confusing. You either have specific group of people with dedicated responsibilities as a group with specific name (Scrum team, architecture team, Centre of Excellence, etc) or a single person. I never heard group of people say about themselves: “Our role is architecture owner!” or any other role in that sense.
So, what is the point of having a role if whole team should fulfil it?! It is just a responsibility or discipline that needs to be taken care of. What is this need to introduce new roles? The suggestion that with such role team would better take care of architectural aspects does not make much sense. Teams might need knowledge and experience to fulfil their responsibility for certain aspect as architecture, but that has nothing to do with ownership or having a role.
In contrary, teams tend to neglect certain responsibilities simply because someone else is appointed and granted a role called blablabla owner. How ironic, the whole problem of taking responsibility is actually created by people whose intentions are to solve it.
It it were some very specific task, which requires knowledge very few people have and it must be done properly, I would understand. But, architecture is one the most important disciplines in software development. It is extremely important that whole team feels responsible and most team members should have the knowledge for dealing with complexities of architecture. The reality is of course that many teams do not have this knowledge. Very often this proves to be the cause of total failure of an Agile team. There are many ways to solve this problem. Introducing a new role is not one of them. It merely maintains suboptimal state of having one or few people keeping responsibility from the place it should be.
Every single Enterprise Architect I know is or use to be an IT guy. Most of them are saying they are responsible for creating or adjusting processes, policies, flow of information, resource management and technology of their organisation. In reality, almost all of them are busy with technology, and maybe information part. At best, they are making nice pictures of business processes and information. There are certainly people responsible for execution of business strategy, but somehow they don’t call themselves Enterprise Architects. These people are often C-level managers or work for a policy department. “Enterprise Architects” might give advises to these people, but they are never part of the club. At least not in any organisation I’ve seen.
No matter how much we discuss term Enterprise Architecture – and there are really many of them, in reality it is always about making decisions about some combination of IT systems within one organisation seen from different perspectives (workplaces, software, infrastructure, integration, middleware, hardware, and so on). Enterprise Architects are very much concerned with processes, information flowing between departments and people, policies, strategy, but these are mere inputs for making IT decisions. At best, certain IT limitations or capabilities can influence business decisions in making or adjusting business processes.
Therefore, difference between Enterprise and Software is just a matter of scale and limited number of different aspects. The rest should be treated the same way. Btw, term software architecture in this context can be replaced with solution or system architecture. This distinction is also just as much relevant.
Let me explain. The first question would be: Which input is not relevant in creating either of them?
- Business processes
When creating a specific solution it is very much important that processes in specific software solution represent and are aligned with one or more business processes.
- Strategy and Business Vision
One of the first things an Agile team does is get together with business people and define a Production Vision Board. One of the typical inputs here is a story from people responsible for strategy to explain the ultimate business goal.
Domain-Driven Design is one of the most important practices in designing software solutions. The most important message of DDD is ubiquitous language. It means that terminology in code should be same as terminology used by business / users. In other words, developers are required to understand information on enterprise level, but only scaled down to their specific domain. Wether one defines Canonical Data Model, master data, reference data, or whatever terminology used, none of these are lacking in one software solution. Only terminology might be different. The difference is again only scale, and speed of change. Knowledge and practices in defining and partitioning information across different systems are same when defining one system.
Another question is wether concerns and practices are so different:
- Workplace, hardware, infrastructure, network
Any of these aspects are very much important when delivering a solution for obvious reasons. There are software / solution architects or teams only concerned with code, but that is just simply irresponsible in Agile environments.
- Design practices
A nice example here are SOLID principles. I wish anyone who call himself Enterprise Architect could learn these principles. Especially when creating services in SOA. Our enterprise landscapes would become “clean enterprise landscapes”, just like we practice clean code.
- Quality requirements
The same as for one system, the direction in enterprise landscape being formed is based on required quality requirements like security, capacity, availability, and so on. These might be different for different systems, but same rules apply to a single system. Some parts of one solution are allowed to be less available.
I could go on with many more examples, but I invite you to challenge me in this statement first. What makes Enterprise Architecting so special? Of course, you will need to agree on my definition of Enterprise Architecture first. 🙂