Sketching the enterprise context from an IT perspective
I've been working with a number of teams recently, helping them to diagram their software systems using the C4 approach that is described in my Software Architecture for Developers book. To summarise, it's a way to visualise the static structure of a software system using a small number of simple diagrams as follows:
- Context: a high-level diagram that sets the scene; including key system dependencies and actors.
- Containers: a containers diagram shows the high-level technology choices (web servers, application servers, databases, mobile devices, etc), how responsibilities are distributed across them and how they communicate.
- Components: for each container, a components diagram lets you see the key logical components/services and their relationships.
- Classes: if there’s important information that I want to portray, I’ll include some class diagrams. This is an optional level of detail and its inclusion depends on a number of factors.
In the real-world, software systems never live in isolation and it's often useful to understand how all of the various software systems fit together within the bounds of an enterprise. To do this, I'll simply add another diagram that sits on top of the C4 diagrams, to show the enterprise context from an IT perspective. This usually includes:
- The organisational boundary.
- Internal and external users.
- Internal and external systems (including a high-level summary of their responsibilities and data owned).
Essentially this becomes a high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. Caveat time. I do appreciate that enterprise architecture isn't simply about technology but, in my experience, many organisations don't have an enterprise architecture view of their IT landscape. In fact, it shocks me how often I come across organisations of all sizes that lack such a holistic view, especially considering IT is usually a key part of the way they implement business processes and service customers. Sketching out the enterprise context from a technology perspective at least provides a way to think outside of the typical silos that form around IT systems.
Slides, video and photos from the event
The Software Architect 2013 conference was a fantastic few days of learning and talking about everything software architecture related. Here are links to the video, slides and photos from my sessions.
- Video from "Software architecture and the balance with agility"
- Slides from "Software architecture and the balance with agility"
- Photos from the "Agile software architecture sketches" workshop
Why are some teams successful while others are less than stellar? Can teams use processes to do their work? How can managers help teams to become better? And do we need incentives to improve the quality of software? These are some of the topics that Simon Brown talked about at the GOTO Amsterdam conference earlier this year in Sustainable competence - the people vs process and technology.
InfoQ did an interview with Simon Brown, in which he talks about sustainable competence for continuous improvement, balancing people and processes, and software quality and architecture.
My Software Architecture for Developers ebook is nearing completion, with a handful of remaining essays to be added and a final round of copyediting to be done. A few people have recently asked me what the inspiration was behind writing the book in the first place, so here you go...
Like many people, I started my career as a software developer, taking instruction from my seniors and working with teams to deliver software systems. Over time, I started designing smaller pieces of software systems and eventually evolved into a position where I was performing what I now consider to be the software architecture role.
I've worked for software consulting organisations for the majority of my career, and this means that most of the projects that I've been involved with have resulted in software systems being built either for or with our customers. In order to scale an software consulting organisation, you need more people and more teams. And to create more teams, you need more software architects. And this leads me to why I wrote the book:
- Software architecture needs to be more accessible: Despite having some fantastic mentors, I didn't find it easy to understand what was expected of me when I was moving into my first software architecture roles. Sure, there are lots of software architecture books out there, but they seem to be written from a different perspective. I found most of them very research oriented or academic in nature, yet I was a software developer looking for real-world advice. I wanted to write the type of book that I would have found useful at that stage in my career - a book about software architecture aimed at software developers.
- All software projects need software architecture: I like agile approaches, I really do, but the lack of explicit regard for software architecture in many of the approaches doesn't sit well with me. Agile approaches don't say that you shouldn't do any up front design, but they often don't explicitly talk about it either. I've found that this causes people to jump to the wrong conclusion and I've seen the consequences that a lack of any up front thinking can have. I also fully appreciate that big design up front isn't the answer either. I've always felt that there's a happy medium to be found where *some* up front thinking is done, particularly when working with a team that has a mix of experiences and backgrounds. I favour a lightweight approach to software architecture that allows me to put *some* building blocks in place as early as possible, to stack the odds of success in my favour.
- Lightweight software architecture practices: I've learnt and evolved a number of practices over the years, which I've always felt have helped me to perform the software architecture role. These relate to the software design process and identifying technical risks through to communicating and documenting software architecture. I've always assumed that these practices are just common sense, but I've discovered that this isn't the case. I've taught these practices to thousands of people over the past few years and I've seen the difference they can make. A book helps me to spread these ideas further, with the hope that other people will find them useful too.
The book isn't about creating a new approach to software development, but it does seek to find a happy mid-point between the excessive up front thinking typical of traditional methods and the lack of any architecture thinking that often happens in software teams who are new to agile approaches. There is room for up front design and evolutionary architecture to coexist.
Agilní snídaně se Simonem Brownem
While there, I presented an Agile Breakfast session in Prague, which was organised by the local Agilia community. The topic was software architecture and the balance with agility.
You can find a short write-up in Czech at Agilní snídaně se Simonem Brownem and the discussion was superb, so thanks to everybody who came along. As usual, the slides from the presentation part are available to view online. I look forward to returning to the Czech Republic in 2014.
While in The Netherlands for ASAS 2013, I also ran my "effective software architecture sketches" session as a guest workshop for eighty students at the HAN University of Applied Sciences. HAN definitely falls on the more practical side of universities and a number of the lecturers actually work part-time in industry. The benefits of this are huge, with the students being exposed to the latest trends in the software development industry. Student assignments include a blend of modern software development approaches alongside the classics that every software developer should know. After graduation, these students will enter the industry with a better grounding in modern software development practices than a huge percentage of the existing industry. Super-inspiring.
I'm always happy to support educational establishments so if you'd like free copies of my Software Architecture for Developers book (for example), just get in touch.
Agility and the essence of software architecture
I had the pleasure of delivering the opening keynote at the Agile Software Architecture Symposium that took place in The Netherlands last week. My talk was called "Agility and the essence of software architecture" and the slides are available to view online.
My keynote at the conference last year primarily focussed on the perceived conflict between software architecture and agile approaches, specifically related to the role of software architects and how much up front thinking should be done when undertaking a software project. This year I focussed more on what agility means, how to create a software architecture than is "agile" and some of the practices that support this. I finished by sharing my experience of how teams can influence change by introducing, or sometimes reintroducing, these practices.
I ran a couple of half-day training sessions yesterday, both of which were basically cut-down versions of the full 2-day Software Architecture for Developers training course. The major difference was that both of these sessions were for non-developers such as business analysts, project managers, testers and project management office staff. Given that many of these people do, or should, work closely with software architects, I asked them what their expectations of the software architecture role were. Here's what they said.
I think this is fascinating, especially because their definition of the role is better than I've seen from some developers! On the subject of whether software architects should be hands-on and write code, their response was "yes, it keeps their hand in". Brilliant. :-)
Over the last decade, studies have shown that, despite the dominance of source code, sketches and diagrams play a major role in software engineering practice.
The focus of our current research is to expand our knowledge on the use of sketches and diagrams in software engineering practice. We are particularly interested in how these visual artifacts are related to source code. We do not exclusively focus on software developers, but on all "software practitioners" including testers, architects, project managers, but also researchers and consultants.
If you think that you belong to this group of software practitioners, please help us gaining deeper insights into your work practice by participating in our short survey. It just takes five to ten minutes of your valuable time:
For more information, don't hesitate to contact me.
Thanks in advance for your participation!
See me talk in pixels or live
Back in March I spoke at QConLondon 2013 on the topic of "Modern Legacy Systems". The video, along with synchronised slides, is now available here. Having just re-watched it I am reminded that I need to work on my timings for presentations (to avoid being gesticulated at to hurry up).
This is especially the case as I'm giving an updated version at Skills Matter as an In The Brain talk. Hope to see you there!