Error getting theme layout

When Skeletons Walk

Posted @ 1:00 pm by Chad Iverson | Category: Strategy, Technology, Web Development Process | 0 Comments

The walking skeleton is a metaphor that we use to describe early-stage technology deliverables. According to Cockburn (2004), the walking skeleton is a simplified implementation of a working system. This is a thin vertical slice of the technology stack providing fundamental connectivity between moving parts in a solution. The skeleton walks when the first implemented end-to-end feature can be demonstrated. The early-stage deliverables may look different for each project, but the benefits are the same.

Development teams at SolutionSet aim for client collaboration early and often. A high-level architecture and initial requirements are agreed upon before the development process begins. The walking skeleton is used to surface risks early in development, promote a shared vision, and support requirements progression. Primitive versions of user interface (UI) typically appear as basic integration tasks are complete. With each development iteration, the client reviews working software. The walking skeleton is more than just a front-end component or proof of concept; it is an actual system architecture that evolves as functionality is added.

what can zombies teach us?

A recent hallway conversation with Adam prompted us to join forces on this blog post. When I asked him for some thoughts on the walking skeleton, he gave me a draft that opened up with a zombie story. His analogy, below, illustrates what a zombie game can teach us about systems architecture.

When I was in college, my group of friends and I were invigorated game players. Time between studying, or instead of studying, was spent in intense coffee table warfare. One of the best loved of these games was Zombie Diner.

Zombie Diner focused on the kitchen staff of an undead diner, where the kitchen staff had to prepare the food, but only had one brain to share between them. The goal was to move the brain around to the zombie that needed it for a specific task. As much as this imagery appealed to our young, slightly soaked brains, it turns out that the game had to be won in the early stages, where you positioned your zombie staff, and the food stations. The actual making of McProduct was pre-ordained by your initial setup. This was later formalized in the dissertation: Optimization Strategies in Tightly Resource Constrained Distribution Networks vis-a-vis the Zombiepocalipse.

In short: After the game starts, every configuration change comes at a cost. This story helps us reflect on prior project experiences. With this, we recognize the importance of early-stage technology deliverables. The challenges that come with each implementation should be identified early.

social business systems architecture

The majority of our development projects focus on the integration of large systems. Social computing platforms cannot provide value to clients in a silo. Most clients prefer best-of-breed solutions that incorporate their existing systems and vendors. Existing systems often source e-commerce capabilities, user data, and content that needs to be socialized; each of these require some level of integration.

Trends in the software market are only increasing the need to focus on system integration. Software as a service (SaaS) and platform as a service (PaaS) have become increasingly popular delivery models for business applications. These models can reduce or eliminate many costs typically associated with owning and operating commercial software. Moreover, there has been a significant shift in favor of search features over portal-based solutions. Web portals commonly require information and functionality to be preconfigured for a particular web destination, whereas search and federated login allow users to pull content and functionality with greater flexibility. Application development previously required on-premise technology integration and emphasized the web layer, this is no longer always the case. We have witnessed a pronounced move toward federated architectures. Oftentimes, systems are loosely coupled and distributed at every layer. Widely recognized benefits of this move include autonomy and agility (Heimbigner & McLeod, 1985; Seth & Larson, 1990); nevertheless related complications must be planned for.

let’s take an example case

A client wants to build a new federated system that contains a) the corporate site; b) a community site; c) federated login; d) an e-commerce site. Internal and external user community outreach is the theme or top-level objective driving this initiative. The proposed architecture takes into account stated needs for a corporate site to serve as the primary user entry-point, local editorial management of corporate content, a best-of-breed social media engine, and a digital storefront. In addition, federated identity management is required; additional technical requirements are expected to emerge during implementation. Detailed user stories are still under consideration.

Federated systems can come in many shapes and sizes. This model represents a fairly simple structure. We have delivered systems having eight or more components. On one project, the diagram was cheerfully referred to as the satan diagram.

A simple and ordered architecture can be deceiving. Each system in the model above represents a complex system in and of itself. Furthermore, the interactions between these applications and systems form an arbitrarily complex conversation, even before any customizations are applied.

the breadth-first approach

The simplicity of a high-level model may tempt development teams to apply functional decomposition; however, this should be limited to analysis. Functional decomposition often leads to a depth-first development approach which entails late-stage integration. This approach may work when the problem being solved is well understood; yet, this is rarely the case with system integration and software development. Depth-first development of individual applications or components amounts to risk, especially in situations where requirements can evolve. The accumulation of technical debt is arguably the most serious of these risks. According to Cunningham (1992), “entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.” Delaying integration tasks can create rework, add costs to a project, and reduce the quality of deliverables.

We recommend early integration following the breadth-first approach. According to Poppendieck and Poppendieck (2003), this approach can help catch sizable issues before they inflict too much damage. The process starts by developing a thin slice of functionality that integrates, at some level, all the systems and applications in a federation. This unpolished working product is our walking skeleton. The idea is to vet not only the individual applications but also their cooperation. Risk can be greatly reduced by solving the breadth of the problem first.

putting it into practice

Following the breadth-first approach, developers should be extremely careful not to overcommit on the first sprint. User stories must be broken down into coherent tasks to effectively plan deliverables. This is especially true for the early stages of a project. We recommend delivering a walking skeleton on the fist sprint; again, this is the smallest meaningful integration achievable. A development team can more easily accomplish this with a finite set of user stories.

A walking skeleton, for our example case above, consists of only basic connections between each system. As a result, the first sprint includes a collection of simple user stories. For the first sprint we might demonstrate a working federated login, navigation between sites, and back-end integration between the e-commerce site and the content management system. Thin vertical slices of functionality from each system are combined to achieve the smallest meaningful integration.



Setting up this very small integration forces a number of issues to the fore that would not otherwise be dealt with until much later in the project. To illustrate, let’s take a look at some questions that come to light in early sprints. The answers to these questions are likely to affect the scope of the overall project, the size of the effort, and requirements prioritization.

Data Layer

It’s important to remember that each system in a federation will have its own identification regime for users and content. Federated identity requirements might be examined here. With content, we frequently see a need for sharing among participating applications or components. In some cases, it is necessary to create globally unique identifiers (GUIDs) for shared objects. Other technical requirements can be uncovered with an initial linkage.

Application Layer

Setting up a working web content management system (WCMS) can bring to life questions about shared headers and footers, navigation, taxonomy, etc. These may also encourage a product owner to consider overlooked requirements in the areas of branding, visual design, and user experience.


Identifying all the interfaces early in the process helps us establish mutually agreeable service contracts. It can be difficult to manage change in distributed systems without a well understood application programming interface (API).


We caution against spending huge amounts of time actually solving all the uncovered issues. The end solution is rarely known at the start, so we plan to adapt and build the system for change. Taking time to answer every question noted during the first sprint will make a process less agile. A walking skeleton is meant to be a working system that matures in conjunction with evolving requirements. This is not a framework to prove a technical concept or to seed a big design up front (BDUF) effort. Backlog grooming and subsequent sprint planning sessions will benefit simply from knowing that the uncovered issues exist.

Without solving every issue, developers can use a number of techniques to maintain momentum. We use façades in the place of external systems ahead of final API availability. Mocks and stubs can be used to fill-in where development is incomplete. At the data layer, a full data migration or reconciliation is not required before other technical tasks begin. The interfaces between the different application domains can be complicated from the start. These interfaces typically become more complicated over time, as changes are made to individual applications or components. The use of these techniques allows us to extend the skeleton, swiftly demonstrate potential functionality, and support requirements exploration.


To sum up, this approach does not address every development challenge; however, it allows us to deliver a working system as quickly as possible. We expect detailed user stories to evolve after development begins. Producing an end-to-end implementation in early stages reduces related risk. Finally, the walking skeleton helps keep solutions aligned with client expectations at every step.


Authors: Chad Iverson, Software Architect, and Adam Trissel, Head of Java Development at SolutionSet.


Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley, Reading, MA.

Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA’ 92 Experience Report. Retrieved from

Heimbigner, D., & McLeod, D. (1985). A federated architecture for information management. ACM Transactions on Information Systems, 3(3), 253–278. doi:10.1145/4229.4233

Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit. Thinking (p. 240). Addison-Wesley.

Sheth, A. P., & Larson, J. A. (1990). Federated database systems for managing distributed, heterogeneous, and autonomous databases. ACM Computing Surveys, 22(3), 183–236. doi:10.1145/96602.96604

Leave a reply

Error getting theme layout