Architecture

Leading software companies have discovered that developing capable technology is not enough to guarantee long-term success. To stay relevant, software leaders need to develop and support the repeatable systems necessary to develop and sustain knowledge and expertise. Many organizations have taken inspiration from Spotify’s culture and adopted the concept of a guild or community of practice to connect engineers throughout the organization and steer them towards common goals. As organizations adopt this model, what is often missing is a clear understanding of the purpose of communities of practice and a repeatable process for developing the communities to their fullest potential. This post provides some guidance based on our experience developing a community of practice at Workiva, it also includes some best practices from the book Cultivating Communities of Practice. ...

Complex processes may require collaboration and coordination of many components. We can model such processes using a Design Structure Matrix to represent information flow among the components, and then optimize the process to avoid rework and downtime. As a simplified example, consider a project with only two tasks: “A” and “B”, and a directed graph representing this system where a vertex represents a task and an edge represents the flow of information between tasks. Depending on the process being modeled, these two vertices can be arranged in one of three different configurations. ...

After graduating from university my (future) wife and I travelled and worked in Kenya as part of the Commonwealth of Learning — an intergovernmental agency dedicated to open learning and distance education. As fortune would have it, my brother had an internship in the neighbouring country of Tanzania during the same time period, and we were able to meet for a few days to enjoy the East African coast in the city of Mombasa. ...

To meet the challenges of scaling systems in size, scope, and complexity, it is useful to look at new approaches and theories to analyze, design, deploy, and manage these systems. A Design Structure Matrix (DSM) is an approach that supports the management of complexity by focusing attention on the elements of complex systems and how they relate to each other. DSM‐based techniques have proven to be very valuable in understanding, designing, and optimizing product, organization, and process architectures. This article explores in more depth how we can use the techniques developed by the design structure matrix community to improve software architecture. ...

Large organizations have a lot of layers. From the C-Suite that is concerned about strategy and vision, to middle management who are executing on projects and programs, down to individual contributors working on project features. These layers provide a number of advantages, all derived from being able to better manage complexity. For example, layers provide a nice separation of concerns: as a software engineer, I don’t have to worry about tax codes and payroll because the finance department can take care of this. As an intern, I don’t need to worry about the global marketing strategy, I can just take care of implementing the widgets we need delivered to customers. ...

Inspiration for software architecture often comes from the world of building architecture. In building architecture, the architect takes in local building codes to understand construction requirements. They analyze various building components like ductwork and furnaces, windows and doors, and figure out where and when to use standard components and when to build custom. They provide cost estimates for each of the components and for the whole, and then build out a blueprint providing upfront design and specification. ...

I recently had the pleasure of being part of the Tied to Machines podcast. We talked about the role of architecture, architectural leadership, and the intersection between architecture and business. You can listen to the full episode here.

Software is core to the operation of our business, and as architects, we are the key conduit between business and technology. Being technical leaders within this intertwined relationship means that we have a responsiblity to make sure that our business decisions and our technology decisions stay aligned. Being in this position demands leadership skills that are equal or better than our technical skills, so that we can effectively align business strategy with technical strategy, communicate that strategy to teams, motivate both teams and individuals, and influence outcomes. ...

One of the many paradoxes of human creativity is that it seems to benefit from constraints. Although we [perceive] the imagination as requiring total freedom, the reality of the creative process is that it’s often entangled with strict conventions and formal requirements. Pop songs have choruses and refrains; symphonies have four movements; plays have five acts; painters still rely on the tropes of portraiture. Jonah Lehrer Constraints can seem like the last thing you’d want for a creative project, but they’re actually beneficial when it comes to doing good work. Anyone who has written knows the hurdle of the blank page, and the feeling that comes from being paralysed by innumerable choices. By restricting the choices available to us, paralysis disappears and we can focus on the task at hand. Don’t believe me? Consider the task of writing an entire story in less than six words. It seems impossible! How can you develop characters, expand a plot, and tell a tale in six words? Here’s how Hemingway did it: ...

The Research and Development department would appear to give equal weight to both research and development by virtue of naming, yet there are few engineers who would claim that research is a primary responsibility of their job. Between working on product features, planning sprints, fixing bugs, and attending meetings there is little time left for research. But what is the cost of foregoing research in favour of development? In this article, I consider the economic cost of ignoring research and argue that focusing solely on development is harmful to both product and engineering. ...