Architecture

In a shopping cart, the swivel wheels of the cart are set in the front, and the fixed wheels are set in the back. Now picture yourself pushing a shopping cart backwards. Almost naturally, you swivel the cart to move the front end to one side or the other before beginning to push the cart. Now picture yourself pushing a shopping cart backwards, on an ice rink. Here, the cart keeps sliding around even after you’ve stopped pushing it. Instead of going straight from one end of the rink to the other, the cart makes giant S-shaped turns. ...

Engineering, for much of the twentieth century, was mainly about artifacts and inventions. Now, it’s increasingly about complex systems. As the airplane taxis to the gate, you access the Internet and check email with your PDA, linking the communication and transportation systems. At home, you recharge your plug-in hybrid vehicle, linking transportation to the electricity grid. At work, you develop code, commit it to a repository, run test cases, deploy to production, and monitor the result. Today’s large-scale, highly complex systems converge, interact, and depend on each other in ways engineers of old could barely have imagined. As scale, scope, and complexity increase, engineers consider technical and social issues together in a highly integrated way as they design flexible, adaptable, robust systems that can be easily modified and reconfigured to satisfy changing requirements and new technological opportunities. ...

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. ...