Software Architecture for Developers: Technical leadership by coding, coaching, collaboration, architecture sketching and just enough up front design (2014)
VI. SOFTWARE ARCHITECTURE IN THE DEVELOPMENT LIFE CYCLE
This, the final part of the book, is about how everything else covered in the book fits into the day-to-day world of software development. We’ll also answer the question of how much software architecture (and therefore, up front design) you should do.
62 The conflict between agile and architecture - myth or reality?
The words “agile” and “architecture” are often seen as mutually exclusive but the real world often tells a different story. Some software teams see architecture as an unnecessary evil whereas others have reached the conclusion that they do need to think about architecture once again.
Architecture can be summarised as being about structure and vision, with a key part of the process focussed on understanding the significant design decisions. Unless you’re running the leanest of startups and you genuinely don’t know which direction you’re heading in, even the most agile of software projects will have some architectural concerns and these things really should be thought about up front. Agile software projects therefore do need “architecture”, but this seems to contradict with how agile has been evangelised for the past 10+ years. Put simply, there is no conflict between agile and architecture because agile projects need architecture. So, where is the conflict then?
Conflict 1: Team structure
The first conflict between architecture and agile software development approaches is related to team structure. Traditional approaches to software architecture usually result in a dedicated software architect, triggering thoughts of ivory tower dictators who are a long way removed from the process of building software. This unfortunate stereotype of “solution architects” delivering large design documents to the development team before running away to cause havoc elsewhere has resulted in a backlash against having a dedicated architect on a software development team.
One of the things that agile software development teams strive towards is reducing the amount of overhead associated with communication via document hand-offs. It’s rightly about increasing collaboration and reducing waste, with organisations often preferring to create small teams of generalising specialists who can turn their hand to almost any task. Indeed, because of the way in which agile approaches have been evangelised, there is often a perception that agile teams must consist of cross-discipline team members and simply left to self-organise. The result? Many agile teams will tell you that they “don’t need no stinkin’ architects”!
Conflict 2: Process and outputs
The second conflict is between the process and the desired outputs of agile versus those of big up front design, which is what people usually refer to when they talk about architecture. One of the key goals of agile approaches is to deliver customer value, frequently and in small chunks. It’s about moving fast, getting feedback and embracing change. The goal of big design up front is to settle on an understanding of everything that needs to be delivered before putting a blueprint (and usually a plan) in place.
The agile manifesto values “responding to change” over “following a plan”, but of course this doesn’t mean you shouldn’t do any planning and it seems that some agile teams are afraid of doing any “analysis” at all. The result is that in trying to avoid big up front design, agile teams often do no design up front and instead use terms like “emergent design” or “evolutionary architecture” to justify their approach. I’ve even heard teams claim that their adoption of test-driven development (TDD) negates the need for “architecture”, but these are often the same teams that get trapped in a constant refactoring cycle at some point in the future.
Software architecture provides boundaries for TDD, BDD, DDD, RDD and clean code
One of the recurring questions I get asked whenever I talk to teams about software architecture is how it relates to techniques such as TDD, BDD, DDD, RDD, etc. The question really relates to whether xDD is a substitute for “software architecture”, particularly within “agile environments”. The short answer is no. The slightly longer answer is that the process of thinking about software architecture is really about putting some boundaries in place, inside which you can build your software using whatever xDD and agile practices you like.
For me, the “why?” is simple - you need to think about the architectural drivers (the things that play a huge part in influencing the resulting software architecture), including:
· Functional requirements: Requirements drive architecture. You need to know vaguely what you’re building, irrespective of how you capture and record those requirements (i.e. user stories, use cases, requirements specifications, acceptance tests, etc).
· Quality attributes: The non-functional requirements (e.g. performance, scalability, security, etc) are usually technical in nature and are hard to retrofit. They ideally need to be baked into the initial design and ignoring these qualities will lead you to a software system that is either over- or under-engineered.
· Constraints: The real-world usually has constraints; ranging from approved technology lists, prescribed integration standards, target deployment environment, size of team, etc. Again, not considering these could cause you to deliver a software system that doesn’t complement your environment, adding unnecessary friction.
· Principles: These are the things that you want to adopt in an attempt to provide consistency and clarity to the software. From a design perspective, this includes things like your decomposition strategy (e.g. layers vs components vs micro-services), separation of concerns, architectural patterns, etc. Explicitly outlining a starting set of principles is essential so that the team building the software starts out heading in the same direction.
Separating architecture from ivory towers and big up front design
These conflicts, in many cases, lead to chaotic teams that lack an appropriate amount of technical leadership. The result? Software systems that look like big balls of mud and/or don’t satisfy key architectural drivers such as non-functional requirements.
Architecture is about the stuff that’s hard or costly to change. It’s about the big or “significant” decisions, the sort of decisions that you can’t easily refactor in an afternoon. This includes, for example, the core technology choices, the overall high-level structure (the big picture) and an understanding of how you’re going to solve any complex/risky/significant problems. Software architecture is important.
Big up front design typically covers these architectural concerns but it also tends to go much further, often unnecessarily so. The trick here is to differentiate what’s important from what’s not. Defining a high-level structure to put a vision in place is important. Drawing a countless number of detailed class diagrams before writing the code most likely isn’t. Understanding how you’re going to solve a tricky performance requirement is important, understanding the length of every database column most likely isn’t.
Agile and architecture aren’t in conflict. Rather than blindly following what others say, software teams need to cut through the hype and understand the technical leadership style and quantity of up front design that they need given their own unique context.
Considering the architectural drivers needn’t take very long and can provide you with a starting point for the rest of the software design activities. Of course, this doesn’t mean that the architecture shouldn’t be changed, especially when you start writing code and getting feedback. The point is that you now have a framework and some boundaries to work within, which provide some often needed vision and guidance for the team. My experience suggests that a little direction can go a long way.
63 Quantifying risk
Identifying risks is a crucial part of doing “just enough up front design” and, put simply, a risk is something bad that may happen in the future, such as a chosen technology not being able to fulfil the promises that the vendor makes. Not all risks are created equal though, with some being more important than others. For example, a risk that may make your software project fail should be treated as a higher priority than something that may cause the team some general discomfort.
Assuming that you have a list of risks (and risk-storming is a great technique for doing this), how do you quantify each of those risks and assess their relative priorities? There are a number of well established approaches to quantifying risk; including assigning a value of low, medium or high or even a simple numeric value between 1 and 10, with higher numbers representing higher levels of risk.
Probability vs impact
A good way to think about risk is to separate out the probability of that risk happening from the negative impact of it happening.
· Probability: How likely is it that the risk will happen? Do you think that the chance is remote or would you be willing to bet cash on it?
· Impact: What is the negative impact if the risk does occur? Is there general discomfort for the team or is it back to the drawing board? Or will it cause your software project to fail?
Both probability and impact can be quantified as low, medium, high or simply as a numeric value. If you think about probability and impact separately, you can then plot the overall score on a matrix by multiplying the scores together as illustrated in the following diagram.
A probability/impact matrix for quantifying risk
Prioritising risk
Prioritising risks is then as simple as ranking them according to their score. A risk with a low probability and a low impact can be treated as a low priority risk. Conversely, a risk with a high probability and a high impact needs to be given a high priority. As indicated by the colour coding…
· Green: a score of 1 or 2; the risk is low priority.
· Amber: a score of 3 or 4; the risk is medium priority.
· Red: a score of 6 or 9; the risk is high priority.
It’s often difficult to prioritise which risks you should take care of and if you get it wrong, you’ll put the risk mitigation effort in the wrong place. Quantifying risks provides you with a way to focus on those risks that are most likely to cause your software project to fail or you to be fired.
64 Risk-storming
Risk identification is a crucial part of doing “just enough up front design” but it’s something that many software teams shy away from because it’s often seen as a boring chore. Risk-storming is a quick, fun, collaborative and visual technique for identifying risk that the whole team can take part in. There are 4 steps.
Step 1. Draw some architecture diagrams
The first step is to draw some architecture diagrams on whiteboards or large sheets of flip chart paper. C4 is a good starting point because it provides a way to have a collection of diagrams at different levels of abstraction, some of which will allow you to highlight different risks across your architecture. Large diagrams are better.
Step 2. Identify the risks individually
Risks can be subjective, so ask everybody on the team (architects, developers, project managers, operational staff, etc) to stand in front of the architecture diagrams and individually write down the risks that they can identify, one per sticky note. Additionally, ask people to quantify each risk based upon probability and impact. Ideally, use different colours of sticky note to represent the different risk priorities. You can timebox this part of the exercise to 5-10 minutes to ensure that it doesn’t drag on and this step should be done in silence, with everybody keeping their sticky notes hidden. Here are some examples of the risks to look for:
· Data formats from third-party systems change unexpectedly.
· External systems become unavailable.
· Components run too slowly.
· Components don’t scale.
· Key components crash.
· Single points of failure.
· Data becomes corrupted.
· Infrastructure fails.
· Disks fill up.
· New technology doesn’t work as expected.
· New technology is too complex to work with.
· etc
As with software development estimates, people’s perceptions of risk can be subjective based upon their experience. If you’re planning on using a new technology, hopefully somebody on the team will identify that there is a risk associated with doing this. Also, somebody might quantify the risk of using new technology relatively highly whereas others might not feel the same if they’ve used that same technology before. Identifying risks individually allows everybody to contribute to the risk identification process and you’ll gain a better view of the risks perceived by the team rather than only from those designing the software or leading the team.
Step 3. Converge the risks on the diagrams
Next, ask everybody to place their sticky notes onto the architecture diagrams, sticking them in close proximity to the area where the risk has been identified. For example, if you identify a risk that one of your components will run too slowly, put the sticky note over the top of that component on the architecture diagram.
Converge the risks on the diagrams
This part of the technique is visual and, once complete, lets you see at a glance where the highest areas of risk are. If several people have identified similar risks you’ll get a clustering of sticky notes on top of the diagrams as people’s ideas converge.
Step 4. Prioritise the risks
Now you can take each sticky note (or cluster of sticky notes) and agree on how you will collectively quantify the risk that has been identified.
· Individual sticky notes: Ask the person who identified the risk what their reason was and collectively agree on the probability and impact. After discussion, if either the probability or impact turns out to be “none”, take the sticky note off of the architecture diagram but don’t throw it away just yet.
· Clusters of sticky notes: If the probability and impact are the same on each sticky note, you’re done. If they aren’t, you’ll need to collectively agree on how to quantify the risk in the same way that you agree upon estimates during a Planning Poker or Wideband Delphi session. Look at the outliers and understand the rationale behind people quantifying the risk accordingly.
Mitigation strategies
Identifying the risks associated with your software architecture is an essential exercise but you also need to come up with mitigation strategies, either to prevent the risks from happening in the first place or to take corrective action if the risk does happen. Since the risks are now prioritised, you can focus on the highest priority ones first.
There are a number of mitigation strategies the are applicable depending upon the type of risk, including:
1. Education: Training the team, restructuring it or hiring new team members in areas where you lack experience (e.g. with new technology).
2. Prototypes: Creating prototypes where they are needed to mitigate technical risks by proving that something does or doesn’t work. Since risk-storming is a visual technique, it lets you easily see the stripes through your software system that you should perhaps look at in more detail with prototypes.
3. Rework: Changing your software architecture to remove or reduce the probability/impact of identified risks (e.g. removing single points of failure, adding a cache to protect from third-party system outages, etc). If you do decide to change your architecture, you can re-run the risk-storming exercise to check whether the change has had the desired effect.
When to use risk-storming
Risk-storming is a quick, fun technique that provides a collaborative way to identify and visualise risks. As an aside, this technique can be used for anything that you can visualise; from enterprise architectures through to business processes and workflows. It can be used at the start of a software development project (when you’re coming up with the initial software architecture) or throughout, during iteration planning sessions or retrospectives.
Just make sure that you keep a log of the risks that are identified, including those that you later agree have a probability or impact of “none”. Additionally, why not keep the architecture diagrams with the sticky notes on the wall of your project room so that everybody can see this additional layer of information. Identifying risks is essential in preventing project failure and it doesn’t need to be a chore if you get the whole team involved.
Collective ownership
As a final point related to risks, who owns the risks on most software projects anyway? From my experience, the “risk register” (if there is one) is usually owned by the lone non-technical project manager. Does this make sense? Do they understand the technical risks? Do they really careabout the technical risks?
A better approach is to assign ownership of technical risks to the software architecture role. By all means keep a central risk register, but just ensure that somebody on the team is actively looking after the technical risks, particularly those that will cause your project to be cancelled or you to be fired. And, of course, sharing the software architecture role amongst the team paves the way for collective ownership of the risks too.
65 Just enough up front design
One of the major points of disagreement about software relates to how much up front design to do. People are very polarised as to when they should do design and how much they should do. From my experience of working with software teams, the views basically break down like this.
· “We need to do all of the software architecture up front, before we start coding.”
· “Software architecture doesn’t need to be done up front; we’ll evolve it as we progress.”
· “Meh, we don’t need to do software architecture, we have an excellent team.”
These different views do raise an interesting question, how much architecture do you need to do up front?
It comes back to methodology
One of the key reasons for the disagreement can be found in how teams work, and specifically what sort of development methodology they are following. If you compare the common software development approaches on account of how much up front design they advocate, you’d have something like the following diagram.
At one end of the scale you have waterfall that, in it’s typical form, suggests big design up front where everything must be decided, reviewed and signed-off before a line of code is written. And at the other end you have the agile approaches that, on the face of it, shy away from doing architecture.
At this point it’s worth saying that this isn’t actually true. Agile methods don’t say “don’t do architecture”, just as they don’t say “don’t produce any documentation”. Agile is about sufficiency, moving fast, embracing change, feedback and delivering value. But since agile approaches and their evangelists don’t put much emphasis on the architectural aspects of software development, many people have misinterpreted this to mean “agile says don’t do any architecture”. More commonly, agile teams choose to spread the design work out across the project rather than doing it all up front. There are several names for this, including “evolutionary architecture” and “emergent design”. Depending on the size and complexity of the software system along with the experience and maturity of the team, this could unfortunately end up as “foolishly hoping for the best”.
Sitting between the ends of the scale are methods like the Rational Unified Process (RUP), Disciplined Agile Delivery (DAD) and DSDM Atern. These are flexible process frameworks that can be implemented by taking all or part of them. Although many RUP implementations have typically been heavyweight monsters that have more in common with waterfall approaches, it can be scaled down to exhibit a combination of characteristics that lets it take the centre ground on the scale. DAD is basically a trimmed down version of RUP, and DSDM Atern is a similar iterative and incremental method that is also influenced by the agile movement. All three are risk-driven methodologies that basically say, “gather the majority of the key requirements at a high level, get the risky stuff out of the way, then iterate and increment”. DSDM Atern even uses the term “firm foundations” to describe this. Done right, these methods can lead to a nice balance of up front design and evolutionary architecture.
You need to do “just enough”
My approach to up front architecture and design is that you need to do “just enough”. If you say this to people they either think it’s an inspirational breath of fresh air that fits in with all of their existing beliefs or they think it’s a complete cop out! “Just enough” works as a guideline but it’s vague and doesn’t do much to help people assess how much is enough. Based upon my definition of architecture, you could say that you need to do just enough up front design to give you structure and vision. In other words, do enough so that you know what your goal is and how you’re going to achieve it. This is a better guideline, but it still doesn’t provide any concrete advice.
It turns out that while “just enough” up front design is hard to quantify, many people have strong opinions on “too little” or “too much” based upon their past experience. Here’s a summary of those thoughts from software developers I’ve met over the past few years.
How much up front design is too little?
· No understanding of what and where the system boundary is.
· No common understanding of “the big picture” within the team.
· Inability to communicate the overall vision.
· Team members aren’t clear or comfortable with what they need to do.
· No thought about non-functional requirements/quality attributes.
· No thought about how the constraints of the (real-world) environment affect the software (e.g. deployment environment).
· No thoughts on key areas of risk; such as non-functional requirements, external interfaces, etc.
· The significant problems and/or their answers haven’t been identified.
· No thought on separation of concerns, appropriate levels of abstraction, layering, modifiability, flex points, etc.
· No common understanding of the role that the architect(s) will play.
· Inconsistent approaches to solving problems.
· A lack of control and guidance for the team.
· Significant change to the architecture during the project lifecycle that could have been anticipated.
· Too many design alternatives and options, often with team members disagreeing on the solution or way forward.
· Uncertainty over whether the design will work (e.g. no prototyping was performed as a part of the design process).
· A lack of technology choices (i.e. unnecessary deferral).
How much up front design is too much?
· Too much information (i.e. long documents and/or information overload).
· A design that is too detailed at too many levels of abstraction.
· Too many diagrams.
· Writing code or pseudo-code in documentation.
· An architecture that is too rigid with no flexibility.
· All decisions at all levels of abstraction have been made.
· Class level design with numerous sequence diagrams showing all possible interactions.
· Detailed entity relationship models and database designs (e.g. tables, views, stored procedures and indexes).
· Analysis paralysis and a team that is stuck focussing on minor details.
· Coding becomes a simple transformation of design artefacts to code, which is boring and demotivating for the team.
· An unbounded “design phase” (i.e. time and/or budget).
· The deadline has been reached without any coding.
How much is “just enough”?
It’s easy to identify with many of the answers above but “just enough” sits in that grey area somewhere between the two extremes. The key is that architecture represents the significant decisions, where significance is measured by cost of change. In other words, it’s the stuff that’s really expensive to modify and the stuff that you really do need to get right as early as possible. For example, qualities such as high performance, high scalability, high security and high availability generally need to be baked into the foundations early on because they are hard to retrofit into an existing codebase. The significant decisions also include the stuff that you can’t easily refactor in an afternoon; such as the overall structure, core technology choices, “architectural” patterns, core frameworks and so on.
Back to RUP for a second, and it uses the term “architecturally significant”, advising that you should figure out what might be significant to your architecture. What might be significant? Well, it’s anything that’s costly to change, is complex (e.g. tricky non-functional requirements or constraints) or is new. In reality, these are the things with a higher than normal risk of consequences if you don’t get them right. It’s worth bearing in mind that the significant elements are often subjective too and can vary depending on the experience of the team.
What you have here then is an approach to software development that lets you focus on what’s risky in order to build sufficient foundations to move forward with. The identification of architecturally significant elements and their corresponding risks is something that should be applied to all software projects, regardless of methodology. Some agile projects already do this by introducing a “sprint zero”, although some agile evangelists will say that “you’re doing it wrong” if you need to introduce an architecture sprint. I say that you need to do whatever works for you based upon your own context.
Although all of this provides some guidance, the answer to “how much is just enough?” needs one of those “it depends” type answers because all software teams are different. Some teams will be more experienced, some teams will need more guidance, some teams will continually work together, some teams will rotate and change frequently, some software systems will have a large amount of essential complexity, etc. How much architecture do you need to do then? I say that you need to do “just enough” in order to do the following, which applies whether the software architecture role is being performed by a single person or shared amongst the team.
1. Structure
o What: Understand the significant structural elements and how they fit together, based upon the architectural drivers.
o How: Design and decomposition down to containers and components.
2. Risks
o What: Identify and mitigate the highest priority risks.
o How: Risk-storming and concrete experiments.
3. Vision
o What: Create and communicate a vision for the team to work with.
o How: Context, container and component diagrams.
This minimal set of software architecture practices will provide you with firm foundations that underpin the rest of the software delivery. Some architecture usually does need to be done up front, but some doesn’t and can naturally evolve. Deciding where the line sits between mandatory and evolutionary design is the key.
Contextualising just enough up front design
In reality, the “how much up front design is enough?” question must be answered by you and here’s my advice … go and practice architecting a software system. Find or create a small-medium size software project scenario and draft a very short set of high-level requirements (functional and non-functional) to describe it. This could be an existing system that you’ve worked on or something new and unrelated to your domain such as the financial risk system that I use on my training course. With this in place, ask two or more groups of 2-3 people to come up with a solution by choosing some technology, doing some design and drawing some diagrams to communicate the vision. Timebox the activity (e.g. 90 minutes) and then hold an open review session where the following types of questions are asked about each of the solutions:
· Will the architecture work? If not, why not?
· Have all of the key risks been identified?
· Is the architecture too simple? Is it too complex?
· Has the architecture been communicated effectively?
· What do people like about the diagrams? What can be improved?
· Is there too much detail? Is there enough detail?
· Could you give this to your team as a starting point?
· Is there too much control? Is there not enough guidance?
· Are you happy with the level of technology decisions that have been made or deferred?
Think of this exercise as an architectural kata except that you perform a review that focusses additionally on the process you went through and the outputs rather than just the architecture itself. Capture your findings and try to distill them into a set of guidelines for how to approach the software design process in the future. Agree upon and include examples of how much detail to go down into, agree on diagram notation and include examples of good diagrams, determine the common constraints within your own environment, etc. If possible, run the exercise again with the guidelines in mind to see how it changes things. One day is typically enough time to run through this exercise with a couple of design/communicate/review cycles.
No two software teams are the same. Setting aside a day to practice the software design process within your own environment will provide you with a consistent starting point for tackling the process in the future and help you contextualise exactly what “just enough” up front design means to you and your team. An additional benefit of practicing the software design process is that it’s a great way to coach and mentor others. Are you striving for a self-organising team where everybody is able to perform the software architecture role?
66 Introducing software architecture
A little software architecture discipline has a huge potential to improve the success of software teams, essentially through the introduction of technical leadership. With this in mind, the final question that we need to address is how to get software teams to adopt a just enough approach to software architecture, to ensure they build well-structured software systems that satisfy the goals, particularly with respect to any complex non-functional requirements and constraints. Often, this question becomes how to we reintroduce software architecture back into the way that software teams work.
In my view, the big problem that software architecture has as a discipline is that it’s competing with all of the shiny new things created in the software industry on a seemingly daily basis. I’ve met thousands of software developers from around the world and, in my experience, there’s a large number of them that don’t think about software architecture as much as they should. Despite the volume of educational material out there, teams lack knowledge about what software architecture really is.
People have limited time and energy for learning but a lack of time isn’t often the reason that teams don’t understand what software architecture is all about. When I was moving into my early software architecture roles, I, like others I’ve spoken to, struggled to understand how much of what I read about in the software architecture books related to what I should doing on a daily basis. This lack of understanding is made worse because most software developers don’t get to practice architecting software on a regular basis. How many software systems have you architected during your own career?
Simply saying that all software teams need to think about software architecture isn’t enough to make it happen though. So, how do we get software teams to reintroduce software architecture?
Software architecture needs to be accessible
As experienced practitioners, we have a duty to educate others but we do need to take it one step at a time. We need to remember that many people are being introduced to software architecture with potentially no knowledge of the related research that has been conducted in the past. Think about the terminology that you see and hear in relation to software architecture. How would you explain to a typical software developer what a “logical view” is? When we refer to the “physical view”, is this about the code or the physical infrastructure? Everybody on the development team needs to understand the essence of software architecture and the consequences of not thinking about it before we start talking about things like architecture description languages and evaluation methods. Information about software architecture needs to be accessible and grounded in reality.
This may seem an odd thing to say, but the people who manage software teams also need to understand the essence of software architecture and why it’s a necessary discipline. Some of the teams I’ve worked with over the years have been told by their management to “stop doing software architecture and get on with the coding”. In many cases, the reason behind this is a misunderstanding that all up front design activities need to be dropped when adopting agile approaches. Such software development teams are usually put under immense pressure to deliver and some up front thinking usually helps rather than hinders.
Some practical suggestions
Here are some practical suggestions for introducing software architecture.
1. Educate people
Simply run some workshops where people can learn about and understand what software architecture is all about. This can be aimed at developers or non-developers, and it will help to make sure that everybody is talking the same language. At a minimum, you should look to cover:
· What software architecture is.
· Why software architecture is important.
· The practices you want to adopt.
2. Talk about architecture in retrospectives
If you have regular retrospectives to reflect on how your team is performing, why not simply include software architecture on the list of topics that you talk about? If you don’t think that enough consideration is being given to software architecture, perhaps because you’re constantly refactoring the architecture of your software or you’re having issues with some non-functional characteristics, then think about the software architecture practices that you can adopt to help. On the flip side, if you’re spending too much time thinking about software architecture or up front design, perhaps it’s time to look at the value of this work and whether any practices can be dropped or substituted.
3. Definition of done
If you have a “definition of done” for work items, add software architecture to the list. This will help ensure that you consider architectural implications of the work item and conformance of the implementation with any desired architectural patterns/rules or non-functional goals.
4. Allocate the software architecture role to somebody
If you have a software team that doesn’t think about software architecture, simply allocating the software architecture role to somebody appropriate on the team may kickstart this because you’re explicitly giving ownership and responsibility for the software architecture to somebody. Allocating the role to more than one person does work with some teams, but I find it better that one person takes ownership initially, with a view to sharing it with others as the team gains more experience. Some teams dislike the term “software architect” and use the term architecture ownerinstead. Whatever you call it, coaching and collaboration are key.
5. Architecture katas
Words alone are not enough and the skeptics need to see that architecture is not about big design up front. This is why I run short architecture katas where small teams collaboratively architect a software solution for a simple set of requirements, producing one or more diagrams to visualise and communicate their solutions to others. This allows people to experience that up front design doesn’t necessarily mean designing everything to a very low level of abstraction and it provides a way to practice communicating software architecture.
Making change happen
Here’s a relatively common question from people that understand why software architecture is good, but don’t know how to introduce it into their projects.
“I understand the need for software architecture but our team just doesn’t have the time to do it because we’re so busy coding our product. Having said that, we don’t have consistent approaches to solving problems, etc. Our managers won’t give us time to do architecture. If we’re doing architecture, we’re not coding. How do we introduce architecture?”
It’s worth asking a few questions to understand the need for actively thinking about software architecture:
1. What problems is the lack of software architecture causing now?
2. What problems is the lack of software architecture likely to cause in the future?
3. Is there a risk that these problems will lead to more serious consequences (e.g. loss of reputation, business, customers, money, etc)?
4. Has something already gone wrong?
One of the things that I tell people new to the architecture role is that they do need to dedicate some time to doing architecture work (the big picture stuff) but a balance needs to be struck between this and the regular day-to-day development activities. If you’re coding all of the time then that big picture stuff doesn’t get done. On the flip-side, spending too much time on “software architecture” means that you don’t ever get any coding done, and we all know that pretty diagrams are no use to end-users!
“How do we introduce software architecture?” is one of those questions that doesn’t have a straightforward answer because it requires changes to the way that a software team works, and these can only really be made when you understand the full context of the team. On a more general note though, there are two ways that teams tend to change the way that they work.
1. Reactively: The majority of teams will only change the way that they work based upon bad things happening. In other words, they’ll change if and only if there’s a catalyst. This could be anything from a continuous string of failed system deployments or maybe something like a serious system failure. In these cases, the team knows something is wrong, probably because their management is giving them a hard time, and they know that something needs to be done to fix the situation. This approach unfortunately appears to be in the majority across the software industry.
2. Proactively: Some teams proactively seek to improve the way that they work. Nothing bad might have happened yet, but they can see that there’s room for improvement to prevent the sort of situations mentioned previously. These teams are, ironically, usually the better ones that don’tneed to change, but they do understand the benefits associated with striving for continouous improvement.
Back to the original question and in essence the team was asking permission to spend some time doing the architecture stuff but they weren’t getting buy-in from their management. Perhaps their management didn’t clearly understand the benefits of doing it or the consequences of not doing it. Either way, the team didn’t achieve the desired result. Whenever I’ve been in this situation myself, I’ve either taken one of two approaches.
1. Present in a very clear and concise way what the current situation is and what the issues, risks and consequences are if behaviours aren’t changed. Typically this is something that you present to key decision makers, project sponsors or management. Once they understand the risks, they can decide whether mitigating those risks is worth the effort required to change behaviours. This requires influencing skills and it can be a hard sell sometimes, particularly if you’re new to a team that you think is dysfunctional!
2. Lead by example by finding a problem and addressing it. This could include, for example, a lack of technical documentation, inconsistent approaches to solving problems, too many architectural layers, inconsistent component configuration, etc. Sometimes the initial seeds of change need to be put in place before everybody understands the benefits in return for the effort. A little like the reaction that occurs when most people see automated unit testing for the first time.
Each approach tends to favour different situations, and again it depends on a number of factors. Coming back to the original question, it’s possible that the first approach was used but either the message was weak or the management didn’t think that mitigating the risks of not having any dedicated “architecture time” was worth the financial outlay. In this particular case, I would introduce software architecture through being proactive and leading by example. Simply find a problem (e.g. multiple approaches to dealing with configuration, no high-level documentation, a confusing component structure, etc) and just start to fix it. I’m not talking about downing tools and taking a few weeks out because we all know that trying to sell a three month refactoring effort to your management is a tough proposition. I’m talking about baby steps where you evolve the situation by breaking the problem down and addressing it a piece at a time. Take a few minutes out from your day to focus on these sort of tasks and before you know it you’ve probably started to make a world of difference. “It’s easier to ask forgiveness than it is to get permission”.
The essence of software architecture
Many software teams are already using agile/lean approaches and more are following in their footsteps. For this reason, any software architecture practices adopted need to add real value otherwise the team is simply wasting time and effort. Only you can decide how much software architecture is just enough and only you can decide how best to lead the change that you want to see in your team. Good luck with your journey!
67 Questions
1. Despite how agile approaches have been evangelised, are “agile” and “architecture” really in conflict with one another?
2. If you’re currently working on an agile software team, have the architectural concerns been thought about?
3. Do you feel that you have the right amount of technical leadership in your current software development team? If so, why? If not, why not?
4. How much up front design is enough? How do you know when you stop? Is this view understood and shared by the whole team?
5. Many software developers undertake coding katas to hone their skills. How can you do the same for your software architecture skills? (e.g. take some requirements plus a blank sheet of paper and come up with the design for a software solution)
6. What is a risk? Are all risks equal?
7. Who identifies the technical risks in your team?
8. Who looks after the technical risks in your team? If it’s the (typically non-technical) project manager or ScrumMaster, is this a good idea?
9. What happens if you ignore technical risks?
10.How can you proactively deal with technical risks?
11.Do you need to introduce software architecture into the way that your team works? If so, how might you do this?