Agile and lean approaches are now no longer seen as niche ways to build software, and even the most traditional of organisations are seeking fast feedback with minimum viable products to prove their ideas. Globally distributed teams are building Internet-scale software systems in all manner of programming languages, with architectures ranging from monolithic systems through to those composed of dozens of microservices. We’ve reached an interesting point in the software development industry. You can find my website at simonbrown.je and I can be found on Twitter at 3. I’ve spoken at events and/or have clients in over thirty countries around the world. In 2013, I won the IEEE Software sponsored SATURN 2013 “Architecture in Practice” Presentation Award for my presentation about the conflict between agile and architecture. I regularly speak at software development conferences, meetups and organisations around the world delivering keynotes, presentations and workshops about software architecture. In addition to being the author of Software Architecture for Developers, I’m the creator of the C4 software architecture model and I built Structurizr, which is a collection of tooling to help you visualise, document and explore your software architecture. I’m an independent software development consultant specialising in software architecture specifically technical leadership, communication and lightweight, pragmatic approaches to software architecture. The core of this is my “C4 model” for visualising software architecture. So while this book doesn’t present a formalised, standardised method to communicate software architecture, it does provide a collection of lightweight ideas and techniques that thousands of people across the world find useful. Although I think it should be an engineering discipline, I believe we’re a number of years away from this being a reality. I’ve seen a number of debates over the years about whether software development is an art, a craft or an engineering discipline. This book focusses on the visual communication and documentation of software architecture. Designing software is where the complexity should be, not communicating it. Over 10,000 people and 30+ countries later, I have gigabytes of anecdotal photo evidence - the majority of the diagrams use an ad hoc “boxes and lines” notation with no clear notation or semantics. I’ve been running software architecture training courses for a number of years, part of which is a simple architecture kata where groups of people are asked to design a software solution and draw some architecture diagrams to describe it. In fact, I was often the only person on the team who really understood UML well enough to create diagrams with it.įast forward to the present day, and creating software architecture diagrams seems to be something of a lost art. I remember seeing a number of software development teams reducing the quantity of diagrams and documentation they were creating. The way teams built software started to change, with things like diagramming and documentation being thrown away alongside big design up front. I also like sketching out solutions to problems, again because it’s a great way to get everything out into the open in a way that other people can understand quickly.īut then something happened somewhere during the early 2000s, probably as a result of the Manifesto for Agile Software Development that had been published a few years beforehand. Visualising the problem is a way for me to ask questions and figure out whether I’ve understood what you’re saying. Talk to me about a business problem and I’m likely to draw a high-level domain model. Describe a business process to me and I’ll sketch up a summary of it. I like being able to visualise a problem before trying to find a solution. With buggy user interfaces and ugly diagrams, the tooling may not have been brilliant back then, but it was still very useful if used in a pragmatic way. A number of the projects I worked on made extensive use of tools like SELECT and Rational Rose for diagramming and documenting the design of software systems. I remember attending a training course about the Unified Modeling Language and the SELECT tooling soon after I started my professional career. I graduated from university in 1996, a time when CASE and modeling tools were popular and in common use.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |