Software Architecture for Developers

A practical and pragmatic guide to software architecture

2012 Simon Brown This version was published on 2012-07-17

This is a Leanpub book, for sale at: http://leanpub.com/software-architecture-for-developers Leanpub helps authors to self-publish in-progress ebooks. We call this idea Lean Publishing. To learn more about Lean Publishing, go to: http://leanpub.com/manifesto To learn more about Leanpub, go to: http://leanpub.com

Tweet This Book!

Please help Simon Brown by spreading the word about this book on Twitter! The suggested hashtag for this book is #sa4d. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: https://twitter.com/search/#sa4d

Contents
Preface About the author Speaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Writing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Want to get in touch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Training i iii iii iii iii iv

Part 0: The prelude

The frustrated architect Software architecture has a bad reputation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agile aspirations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . So you think youre an architect? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From frustration and beyond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2 2 2 3 3

Part 1: What is software architecture?

What is architecture? As a noun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . As a verb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Is software architecture important? A lack of software architecture causes problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . The benefits of software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Does every software project need software architecture? . . . . . . . . . . . . . . . . . . . . . . . Questions

4
5 6 7 8 8 8 9 10

Part 2: The software architecture role

Questions

11
12

CONTENTS

Part 3: Designing software

You dont need a UML tool There are many types of UML tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The simplest thing that could possibly work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . There is no silver bullet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Start with the big picture Wide angle view (the big picture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard view (containers) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Telephoto view (major components/services and their interactions) . . . . . . . . . . . . . . . . . . Macro view (classes and implementation details) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analysis paralysis vs refactor distractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tell a consistent story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13
14 14 14 15 16 16 16 16 17 17 17

Part 4: Communicating software

C4: context, containers, components and classes Summarising the static view of your software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisational ideas, not a standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18
19 19 19

Part 5: Software architecture in the development lifecycle

Quantifying risk Probability vs impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prioritising risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
22 22 23

Part 6: The retrospective

SharePoint projects need software architecture too 1. Many SharePoint implementations arent just SharePoint . . . . . . . . . . . . . . . . . . . . . . 2. Non-functional requirements still apply to SharePoint solutions . . . . . . . . . . . . . . . . . . 3. SharePoint projects are complex and require technical vision too . . . . . . . . . . . . . . . . . .

24
25 25 25 25

CONTENTS

4. SharePoint solutions still need to be documented . . . . . . . . . . . . . . . . . . . . . . . . . . Strong leadership and discipline arent just for software development projects . . . . . . . . . . . . Version history

26 26 27

Preface
The agile and software craftsmanship movements are helping to push up the quality of the software systems that we build, which is excellent. Together they are helping us to write better software that better meets the needs of the business while carefully managing time and budgetary constraints. But theres still more we can do because even a small amount of software architecture can help prevent many of the problems that projects face. Successful software projects arent just about good code and sometimes you need to step away from the IDE for a few moments to see the bigger picture. This book is about that bigger picture and its role in delivering better software. Its a collection of essays that together form a practical and pragmatic guide to software architecture, with the overall goal being to demystify what it means to be a software architect and provide guidance on how to do software architecture effectively. The book is aimed at software developers that want to learn more about software architecture as well as those that are new to the role. It fills the gap between software development and high-level architecture that probably seems a little enterprisey for most developers.

The scope of Software Architecture for Developers

Youll find this book useful if any of the following scenarios sound familiar. Im not sure what software architecture is about and how its any different from design. I dont understand why we need software architecture. My manager has told me that Im the software architect on our new project, but Im not sure what that actually means. I want to get involved in designing software but Im not sure what I should learn. i

Preface

ii

Ive been given some requirements and asked to design some software, but Im not sure where to start. I need to make some major enhancements to my system, but Im not sure where to start. Ive been asked to write a software architecture document but Im not sure what to include in it. Im not sure who to talk to in my organisation about how best to integrate what were building. I understand what software architecture is all about, but Im not sure how to tackle it on my project. My project seems like a chaotic mess; everybody is doing their own thing and theres no shared vision. Help!

About the author

Simon Brown is an independent consultant based in Jersey in the Channel Islands, and is either a software architect who codes or a software developer who understands architecture. Having successfully delivered a variety of projects on the Java and Microsoft .NET platforms, Simon now uses his experience to additionally train and coach teams in delivering better software. He is the founder of Coding the Architecture (a website for hands-on software architects) and regularly works with software teams across Europe, helping them adopt a lightweight pragmatic approach to software architecture.

Speaking
Simon regularly speaks about software development, at events ranging from international software development conferences through to small user groups and specialist events. Videos and slides from many of these events are available view online/download from Coding the Architecture.

Writing
Simon has also written/co-written a number of books and articles in the past, including several books about Java EE technologies.

Want to get in touch?

If you would like to get in touch, please e-mail simon.brown@codingthearchitecture.com or tweet @simonbrown.

http://www.codingthearchitecture.com http://www.codingthearchitecture.com simon.brown@codingthearchitecture.com http://twitter.com/simonbrown

iii

Training
Designing software given a vague set of requirements and a blank sheet of paper is a good skill to have, although not many people get to do this on a daily basis. However, with agile methods encouraging collective ownership of the code, its really important that everybody on the team understands the big picture. And in order to do this, you need to understand why youve arrived at the design that you have. In a nutshell, everybody on the team needs to be a software architect. Software Architecture for Developers is also available as a two-day training course about pragmatic software architecture, designed by software architects that code. It will show you what just enough up front design is, how it can be applied to your software projects and how to communicate the big picture through a collection of simple effective sketches. Its aimed at software developers and architects regardless of whether youre building software in Java, .NET or something else. The course is interactive; with a combination of presentation, group discussion and group working. Throughout the course youll solidify everything you learn through a case study where youll be given a set of requirements, asked to design a small software system and communicate that design.

See http://www.softwarearchitecturefordevelopers.com for more details or if youd like to join us for a mixture of presentation, discussion and deliberate practice.

http://www.softwarearchitecturefordevelopers.com

iv

Part 0: The prelude

The frustrated architect

The IT industry is either taking giant leaps ahead or its in deep turmoil. On the one hand were pushing forward, reinventing the way that we build software and striving for craftsmanship at every turn. On the other though, were continually forgetting the good of the past and software teams are still screwing up on an alarmingly regular basis. Software architecture plays a pivotal role in the delivery of successful software yet its frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the software architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

Software architecture has a bad reputation

I tend to get one of two responses if I introduce myself as a software architect. Either people think its really cool and want to know more or they give me a look that says I want to talk to somebody that actually writes software, not a box drawing hand-waver. The software architecture role has a bad reputation within the IT industry and its not hard to see where this has come from. The thought of software architecture conjures up visions of ivory tower architects doing big design up front and handing over huge UML models or 200 page Microsoft Word documents to an unsuspecting development team as if they were the second leg of a relay race. And thats assuming the architect actually gets involved in designing software of course. Many people seem to think that creating a Microsoft PowerPoint presentation with a slide containing a big box labelled Enterprise Service Bus is software design. Oh, and we mustnt forget the obligatory narrative about ROI and TCO that will undoubtedly accompany the presentation. Many organisations have an interesting take on software development as a whole too. For example, theyve seen the potential cost savings that offshoring can bring and therefore see the coding part of the software development process as being something of a commodity. The result tends to be that local developers are pushed into the higher value software architecture jobs with an expectation that all coding will be undertaken by somebody else. In many cases this only exaggerates the disconnect between software design and software development, with people often being pushed into a role that they are not prepared for. These same organisations tend to see software architecture as a rank rather than a role.

Agile aspirations
Agile might be over ten years old, but its still the shiny new kid in town and many software teams have aspirations of becoming agile. Agile undoubtedly has a number of benefits but it isnt necessarily the silver bullet that everybody wants you to believe it is. As with everything in the IT industry, theres a large degree of evangelism and hype surrounding it. Start a new software project today and its all about self-organising teams, automated acceptance testing, continuous delivery, retrospectives, Kanban boards, emergent design and a whole host of other buzzwords that youve probably heard of. This is fantastic but often teams tend to throw the baby out with the bath water in their haste to adopt all of these cool practices. Non-functional requirements not sounding cool isnt a reason to neglect them.

The frustrated architect

Whats all this old-fashioned software architecture stuff anyway? Many software teams seem to think that they dont need software architects, throwing around terms like self-organising team, YAGNI, evolutionary architecture and last responsible moment instead. If they do need an architect, theyll probably be on the lookout for an agile architect. Im not entirely sure what this term actually means, but I assume that it has something to do with using post-it notes instead of UML or doing TDD instead of drawing pictures. That is, assuming they get past the notion of only using a very high level system metaphor and dont use emergent design as an excuse for foolishly hoping for the best.

So you think youre an architect?

It also turns out there are a number of people in the industry claiming to be software architects whereas theyre actually doing something else entirely. I can forgive people misrepresenting themselves as an Enterprise Architect when theyre actually doing hands-on software architecture within a large enterprise. The terminology in our industry is often confusing after all. But what about those people that tend to exaggerate the truth about the role they play on software teams? Such irresponsible architects are usually tasked with being the technical leader yet fail to cover the basics. Ive seen public facing websites go into a user acceptance testing environment with a number of basic security problems, a lack of basic performance testing, basic functionality problems, broken hyperlinks and a complete lack of documentation. And that was just my external view of the software, who knows what the code looked like. If youre undertaking the software architecture role and youre delivering stuff like this, youre doing it wrong. This isnt software architecture, its also foolishly hoping for the best.

From frustration and beyond

Admittedly not all software teams are like this but what Ive presented here isnt a straw man either. Unfortunately many organisations do actually work this way so the reputation that software architecture has shouldnt come as any surprise. If we really do want to succeed as an industry, we need to get over our fascination with shiny new things and starting asking some questions. Does agile need architecture or does architecture actually need agile? Have we forgotten more about good software design than weve learnt in recent years? Is foolishly hoping for the best sufficient for the demanding software systems were building today? Does any of this matter if were not fostering the software architects of tomorrow? How do we move from frustration to serenity? Read on to find out

Part 1: What is software architecture?

What is architecture?
The word architecture means many different things to many different people and there are many different definitions floating around the Internet. Ive asked hundreds of people over the past few years what architecture means to them and a summary of their answers is as follows. These are in no particular order Modules, connections, dependencies and interfaces The big picture The things that are expensive to change The things that are difficult to change Design with the bigger picture in mind Interfaces rather than implementation Aesthetics (e.g. as an art form, clean code) A conceptual model Satisfying non-functional requirements/quality attributes Everything has an architecture Ability to communicate (abstractions, language, vocabulary) A plan A degree of rigidity and solidity A blueprint Systems, subsystems, interactions and interfaces Governance The outcome of strategic decisions Necessary constraints Structure (components and interactions) Technical direction Strategy and vision Building blocks The process to achieve a goal Standards and guidelines 5

What is architecture?

The system as a whole Tools and methods A path from requirements to the end-product Guiding principles Technical leadership The relationship between the elements that make up the product Awareness of environmental constraints and restrictions Foundations An abstract view The decomposition of the problem into smaller implementable elements The skeleton/backbone of the product No wonder its hard to find a single definition! Thankfully there are two common themes here architecture as a noun and architecture as a verb, with both being applicable regardless of whether were talking about constructing a physical building or a software system.

What is architecture?

As a noun
As a noun then, architecture can be summarised as being about structure and is about the decomposition of a product into a collection of components and interactions. This needs to take into account the whole

What is architecture?

of the product, including the foundations and infrastructure services that deal with cross-cutting concerns such as power/water/air conditioning (for a building) or security/configuration/error handling (for a piece of software).

As a verb
As a verb, architecture (i.e. the process, architecting) is about understanding what you need to build, creating a vision for building it and making design decisions. Crucially, its also about communicating that vision so that everybody involved with the construction of the product understands the vision and is able to contribute in a positive way to its success. Put simply, the process of architecting is about introducing technical leadership.

Is software architecture important?

Software architecture then, is it important? The agile and software craftsmanship movements are helping to push up the quality of the software systems that we build, which is excellent. Together they are helping us to write better software that better meets the needs of the business while carefully managing time and budgetary constraints. But theres still more we can do because even a small amount of software architecture can help prevent many of the problems that projects face. Successful software projects arent just about good code and sometimes you need to step away from the IDE for a few moments to see the bigger picture.

A lack of software architecture causes problems

Since software architecture is about structure and vision, you could say that it exists anyway. And I agree, it does. Having said that, its easy to see how not thinking about software architecture (and the bigger picture) can lead to a number of common problems that software teams face on a regular basis. Ask yourself the following questions: Does your software system have a well defined structure? Is everybody on the team implementing features in a consistent way? Is there a consistent level of quality across the codebase? Is there a shared vision for how the software will be built across the team? Does everybody on the team have the necessary amount of technical guidance? Is there an appropriate amount of technical leadership? It is possible to successfully deliver a software project by answering no to some of these questions, but it does require a very good team and a lot of luck. If nobody thinks about software architecture, the end result is something that typically looks like a big ball of mud. Sure, it has a structure but its not one that youd want to work with! Other side effects could include the software system being too slow, insecure, fragile, unstable, hard to deploy, hard to maintain, hard to change, hard to extend, etc. Im sure youve never seen or worked on software projects like this, right? No, me neither. ;-) Since software architecture is inherent in every software project and system, why dont we simply acknowledge and place some focus on it?

The benefits of software architecture

What benefits can software architecture provide then? In summary: A clear vision and roadmap for the team to follow, regardless of whether that vision is owned by a single person or collectively by the whole team.
http://www.laputan.org/mud/

Is software architecture important?

Technical leadership and better coordination. A stimulus to talk to people in order to answer questions relating to significant decisions, non-functional requirements, constraints and other cross-cutting concerns. A framework for identifying and mitigating risk. Consistency of approach and standards, leading to a well structured codebase. A set of firm foundations for the rest of the project. A structure with which to communicate the solution at different levels of abstraction to different audiences.

Does every software project need software architecture?

Rather than use the typical consulting answer of it depends, Im instead going to say that the answer is undoubtedly yes, with the caveat that every software project should look at a number of factors in order to assess how much software architecture is necessary. These include the size of the project, the complexity of the project, the size of the team and the experience of the team. The answer to how much is just enough will be explored throughout the rest of this book.

Questions
1. Do you know what architecture is all about? Does the rest of your team? What about the rest of your organisation? 2. There are a number of different types of architecture within the IT domain. What do they all have in common? 3. Do you and your team have a standard definition of what software architecture means? Could you easily explain it to new members of the team? Is this definition common across your organisation? 4. Can you make a list of the architectural decisions on your current software project? Is it obvious why they were deemed as significant? 5. If you step back from your IDE, what sort of things are included in your big picture? 6. What does the technical career path look like in your organisation? Is enterprise architecture the right path for you? 7. Is software architecture important? Why and what are the benefits? Is there enough software architecture on your software project? Is there too much?

10

Part 2: The software architecture role

11

Questions
1. Whats the difference between the software architecture and software developer roles? 2. Why is it important for anybody undertaking the software architecture role to understand the technologies that they are using? Would you hire a software architect who didnt understand technology? 3. If youre the software architect on your project, how much coding are you doing? Is this too much or too little? 4. If, as a software architect, youre unable to code, how else can you stay engaged in the low-level aspects of the project. And how else can you keep your skills up to date? 5. Why is having a breadth and depth of technical knowledge as important? 6. Do you think you have all of the required soft skills to undertake the software architecture role? If not, which would you improve, why and how? 7. What does the software architecture role entail? Is this definition based upon your current or ideal team? If its the latter, what can be done to change your team? 8. Does your current software project have enough guidance and control from a software architecture perspective? Does it have too much? 9. Why is collaboration an important part of the software architecture role? Does your team do enough? If not, why? 10. Is there enough coaching and mentoring happening on your team? Are you providing or receiving it? 11. What pitfalls have you fallen into as somebody new to the software architecture role? 12. How does the software architecture role fit into agile projects and self-organising teams?

12

Part 3: Designing software

13

You dont need a UML tool

When tasked with the job of coming up with an architecture and design for a new software system, one of the first questions some people ask relates to the tooling that they should use. Such discussions usually focus around the Unified Modelling Language (UML) and whether their organisation has any licenses for some of the more well-known UML tools.

There are many types of UML tool

Unfortunately this isnt an easy question to answer because there are lots of commercial and open source tools that can help you to do software architecture and design, all tending to approach the problem from a different perspective. At a high-level, they can be categorised as follows. 1. Diagrams only: There are many standalone UML tools and plug-ins for major IDEs that let you sketch simple UML diagrams. These are really useful if you want to be in control of your diagrams and what they portray but its easy for such diagrams to get out of date with reality over time. Microsoft Visio or OmniGraffle with the UML templates are good starting points if you have access to them. 2. Reverse engineering: There are standalone UML tools and IDE plug-ins that allow you to create UML diagrams from code. This is great because you can quickly get the code and diagrams in sync, but often these diagrams become cluttered quickly because they typically include all of the detail (e.g. every property, method and relationship) by default. 3. Round-trip engineering: Many reverse engineering tools also allow you to do round-trip engineering, where changes made to the model are reflected in the code and vice versa. Again, this helps keeps code and diagrams in sync. 4. Model-driven: There are a few model-driven architecture (MDA) tools that let you drive the implementation of a software system from the model itself, usually by annotating the diagrams with desired characteristics and behaviours using languages such as Executable UML (xUML) or Object Constraint Language (OCL). These tools can offer a full end-to-end solution but you do need to follow a different and often rigid development process in order to benefit from them.

The simplest thing that could possibly work

Even this short summary of the categories of tools available makes for an overwhelming number of options. Rational Software Architect? Visio? PowerPoint? OmniGraffle? WebSequenceDiagrams.com? Which do you pick?! The thing is though, you dont need a UML tool in order to architect and design software. Ive conducted a number of informal polls during my conference talks over the past few years and only 10-20% of the audience said that they regularly used UML in their day to day work. Often a blank sheet of paper, flipchart or whiteboard together with a set of post-it notes or index cards is all you need, particularly when you have a group of people that want to undertake the design process in a collaborative way. Have you ever tried to get three or four people collaborating around a laptop screen? 14

You dont need a UML tool

15

You dont need a UML tool

Agile methods have been using this low-tech approach for capturing user stories, story walls and Kanban boards for a while now. In many cases, its the simplest thing that could possibly work but nothing beats the pure visibility of having lots of stuff stuck to a whiteboard in the middle of your office. Unlike a Microsoft Project plan, nobody can resist walking past and having a look at all those post-it notes still in the To do column. From a software design perspective, this low-tech approach frees you from worrying about the complexities of using the tooling and bending formal notation, instead letting you focus on the creative task of designing software. Simply start by sketching out the big picture and work down to the lower levels of detail where necessary. Just remember that you need to explicitly think about things like traceability between levels of abstraction, conventions and consistency if you dont use a tool. For example, UML arrows have meaning and without a key it might not be obvious whether your freehand arrows are pointing towards dependencies or showing the direction that data flows. You can always record your designs in a more formal way using a UML tool later if you need to do so.

There is no silver bullet

Forget expensive tools. More often than not; a blank sheet of paper, flipchart or whiteboard is all you need, particularly when you have a group of people that want to undertake the design process in a collaborative way. Unfortunately theres no silver bullet when it comes to design tools though because everybody and every organisation works in a different way. Once youre confident that you understand how to approach software architecture and design, only then is it time to start looking at software tools to help improve the design process. You dont need UML tools to do architecture and design, but they can be useful.

Start with the big picture

One of the hardest things about the software architecture role is being asked to come up with a software design when all youre given is a set of requirements and a blank piece of paper. Its certainly one of the most fun parts of the role, but it can be a daunting prospect trying to figure out where to start and what to do. Many software teams dive straight into the code and while this can initially be very productive, some soon start to venture down the slippery slope of constant refactoring while they try to settle upon a design that works. Often, a little forethought is all thats needed to get the software development process heading in the right direction. So where do you start?

Wide angle view (the big picture)

One of the first things I do is step back to see the big picture. What exactly is the context here? What is this all about? What is it were building and how does it fit in with the existing environment? A really useful starting point can be to draw a simple block diagram showing your system, the other systems that it interfaces with and key actors. For example, if youre building a website, you might show the website along with the various backend systems that you need to integrate with. Detail isnt important here. Its your wide angle view showing a big picture of the system landscape.

Standard view (containers)

Once you understand how your system fits in to the overall system landscape, a useful next step is to draw another simple block diagram showing all of the containers that make up these systems. By container, I mean anything in which code and data will reside. This includes things like web servers, application servers, Windows services, enterprise service buses, databases, standalone applications, web browser plugins, etc. A high-level diagram like this doesnt necessary show much detail, but it only takes a few minutes to put together and provides a framework for understanding the major building blocks of your software and their interfaces.

Telephoto view (major components/services and their interactions)

Next I start to zoom in and decompose the containers into components, services, subsystems, workflows, etc. However you decompose your system is up to you, but what youre looking for at the telephoto level is a view of the major components and their interactions. If you were building an e-commerce website, you might show components representing a catalog service, a pricing service, a payment service and so on. These are the fundamental building blocks of your system and you should be able to understand how a use case or user story can be implemented across one or more of those major components. If you can do this, then youve most likely captured everything. If, for example, you have a requirement to audit system access but you dont have an audit component, then perhaps youve missed something. Equally, if you have homeless components floating around outside of containers, then perhaps youve forgotten a container.

16

Start with the big picture

17

Macro view (classes and implementation details)

For some software teams, the telephoto picture is enough detail for them to go off and successfully build the software. Others, however, need to go down to a lower level by further decomposing the major components. Typically this is low-level design where you use (for example) object oriented design principles to define how a component will work at the code level. For example, one of your components might be a web page, which you could further decompose to show how it would be implemented using a web-MVC framework. Or perhaps you want to model the business domain in some detail because its complex in some way. You could represent this lower level of detail using anything from simple block diagrams through to formal UML class diagrams, but either way theyre showing the implementation level design aspects of the system. For me, this is an optional level of detail that depends on the size/complexity of the project and size/experience of the team.

Analysis paralysis vs refactor distractor

A logical top-down approach to software design such as this might look like common sense. And to some degree it is, but many software teams dive straight into the macro level without giving the other levels any thought. Diving into the code, tempting as it may be, can lead to designs that are over-engineered, incoherent and inconsistent balls of mud. This is especially true when youre faced with a large team where everybody is tackling system design from a macro level perspective. If youve seen teams that are constantly refactoring at the really early stages of a software project, to the point that its distracting them from the bigger picture, they probably didnt start out with the big picture and enough vision of where they wanted to go. A combination of design and coding will help to prevent analysis paralysis, but diving straight into the code means that you miss out on the opportunity to create a vision of how your software system should be built and youll most likely encounter a whole host of problems further down the line. Analysis paralysis and refactor distractor are both very bad and a balance between design and coding is needed.

Tell a consistent story

The software design process is essential and straightforward if tackled in the right way. My advice is simple; start with the big picture and work your way into the lower levels of detail, remembering that each picture should tell a different part of the same story.

Part 4: Communicating software

18

C4: context, containers, components and classes

The code for any software system is where most of the focus remains for the majority of the software development life cycle and this makes sense because the code is the ultimate deliverable. But if you had to explain to somebody how that system worked, would you start with the code? Unfortunately the code doesnt tell the whole story and, in the absence of documentation, people will typically start drawing boxes and lines on a whiteboard or piece of paper to explain what the major building blocks are and how they are connected. When describing software through pictures, we have a tendency to create a single uber-diagram that includes as much detail as possible at every level of abstraction simultaneously. This may be because were anticipating questions or because were a little too focussed on the specifics of how the system works at a code level. Such diagrams are typically cluttered, complex and confusing. Picking up a tool such as Microsoft Visio, Rational Software Architect or Sparx Enterprise Architect usually adds to the complexity rather than making life easier. A better approach is to create a number of diagrams at varying levels of abstraction. A number of simpler diagrams can describe software in a much more effective way than a single complex diagram that tries to describe everything.

Summarising the static view of your software

I tend to draw the following types of diagrams when summarising the static view of my software, which are based upon a set of simple architectural constructs. 1. Context: a high-level diagram that sets the scene; including key systems and actors. 2. Containers: a container represents something in which components are executed, which could be anything from a web or application server through to a rich client application or database. Drawing a diagram at this level lets you see the containers that make up your software system and the relationships between them. 3. Components: a component can be thought of as a logical grouping of one or more classes that sits inside a container. Drawing a diagram at this level lets you see the key logical components/services and their relationships. 4. Classes: if theres important information that I want to portray, Ill include some class diagrams. This is an optional level of detail and its inclusion depends on a number of factors.

Organisational ideas, not a standard

Just to be clear, C4 is about providing some organisational ideas and guidelines rather than creating a standard. A single diagram can quickly become cluttered and confused, but a collection of simple diagrams allows you to effectively present the software from a number of different levels of abstraction. Feel free to mix the concepts 19

C4: context, containers, components and classes

20

together; this can work really well for small systems where the containers and components diagrams can be merged. Just try to keep the diagrams as simple as possible. If you do this, illustrating your software can be a quick and easy task that requires little ongoing effort to keep those diagrams up to date. You never know, people might even understand them too.

Part 5: Software architecture in the development lifecycle

21

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.

22

Quantifying risk

23

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. Its often difficult to prioritise which risks you should take care of and if you get it wrong, youll put the risk mitigation effort into 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.

Part 6: The retrospective

24

SharePoint projects need software architecture too

Although the majority of my commercial experience relates to the development of bespoke software systems, Ive seen a number of SharePoint and other product/platform implementations where the basic tenets of software architecture have been forgotten or neglected. Heres a summary of why software architecture is important for SharePoint projects.

1. Many SharePoint implementations arent just SharePoint

Many of the SharePoint solutions Ive seen are not just simple implementations of the SharePoint product where end-users can create lists, share documents and collaborate. As with most software systems, theyre a mix of new and legacy technologies, usually with complex integration points into other parts of the enterprise via web services and other integration techniques. Often, bespoke .NET code is also a part of the overall solution, either running inside or outside of SharePoint. If you dont take the big picture into account by understanding the environment and its constraints, theres a chance that youll end up building the wrong thing or building something that doesnt work.

2. Non-functional requirements still apply to SharePoint solutions

Even if youre not writing any bespoke code as a part of your SharePoint solution, that doesnt mean you can ignore non-functional requirements. Performance, scalability, security, availability, disaster recovery, audit, monitoring, etc are all potentially applicable. Ive seen SharePoint projects where the team has neglected to think about key non-functional requirements, even on public Internet-facing websites. As expected, the result was solutions that exhibited poor response times and/or severe security flaws (e.g. cross-site scripting). Often these issues were identified at a late stage in the (usually waterfall) project lifecycle.

3. SharePoint projects are complex and require technical vision too

Like any programming language, SharePoint is a complex platform and there are usually a number of different ways to solve a single problem. In order to get some consistency of approach and avoid chaos, SharePoint projects need strong technical leadership and the software architecture role is as applicable here as it is if youre writing a software system from scratch. If youve ever seen SharePoint projects where a seemingly chaotic team has eventually delivered something of a poor quality, youll appreciate why this is important.

25

SharePoint projects need software architecture too

26

4. SharePoint solutions still need to be documented

With all of this complexity in place, Im continually amazed to see SharePoint solutions that have no documentation. Im not talking about hefty 200+ page documents here, but there should be at least some lightweight documentation that provides an overview of the solution. Some diagrams to show how the SharePoint solution works at a high-level are also useful. C4 works well for SharePoint too and some lightweight documentation can be a great starting point for future support, maintenance and enhancement work; particularly if the project team changes or if the project is delivered under an outsourcing agreement.

Strong leadership and discipline arent just for software development projects
If youre delivering software solutions then you need to make sure that you have at least one person undertaking the technical leadership role, looking after the things that Ive highlighted above. If not, youre doing it wrong. As an aside, all of this applies to other platform products such as Microsoft Dynamics CRM projects, especially if youre just tacking on an Internet-facing ASP.NET website to expose the data via the Internet. Ive mentioned this to SharePoint teams in the past and some have replied but SharePoint isnt software development. Regardless of whether it is or isnt software development, successful SharePoint projects need strong technical leadership and discipline. SharePoint projects need software architecture.

Version history
This book is a work in progress; heres a list of the essays that have been added at each version. 17th July 2012: Containers, Components, SharePoint projects need software architecture too 22nd June 2012: Moving fast requires good communication, Context, Effective sketches, Diagram review checklist 10th May 2012: Quantifying risk, Risk-storming 9th April 2012: The frustrated architect, Everybody is an architect, except when theyre not, Crossing the mythical line or bridging the gaping chasm? 13th March 2012: The software architecture role, Software architecture introduces control, Software development is not a relay sport, Where are the software architects of tomorrow?, Contextualising just enough up front design, Financial Risk System (Appendix A) 11th March 2012: Software architecture is a platform for conversation, C4: context, containers, components and classes, The code doesnt tell the whole story, Mind the gap, Just enough up front design 3rd March 2012: You dont need a UML tool, Architectural constructs, Start with the big picture, Collaborative design, Its easier to ask forgiveness than it is to get permission 21st February 2012: What is architecture?, Types of architecture?, What is software architecture?, Architecture vs design, What is the big picture?, Strategy rather than code, Is software architecture important?

27