IKEA is a company which I admire for its ability to develop innovate, practical, and tasteful products. If you have not looked them up or heard of them, I highly encourage you to visit their website. They offer great products with incredible value. The features of IKEA's products have analogs in software development, which I will discuss.

Several parts of IKEA's furniture delivery model interest myself as a seasoned application architect. IKEA delivers their product to the customer in a sort of a customizable form. The furniture is by no means completely built, but key parts of the piece of furniture are built. IKEA gives the customer the components of whatever they would like to create, but they do not build it for you. This intentional delivery of furniture in an unbuilt, or partially built, form does not just have benefits in terms of fitting the pieces in boxes. The real genius here is the creation of a layer in the furniture product delivery process where the customer can customize the furniture, while also leveraging preset configurations.

There is a clear separation between the people that put these parts together and design them so that they are able to be put together, and the constructor that actually produces the furniture. It is even feasible to make a career out of being an IKEA constructor too! The end result is that you have an entity, be it a team or individual, who constructs the product, while another entity constructs the components of the products and deliver the components to the construction team. What this additional layer provides is a clear separation between those who create the components and those who use the components to create the product.

Briefly, the idea is that IKEA will build the pieces, decide that these are the components that you need, and then say here are the instructions, you can put it together. But, I believe a key component of what makes IKEA product unique is that you can take components of one product and combine it with components of another product to build something completely unique.

The level of customization provided to the customer by IKEA is truly a feat of business and engineering, and part of the reason I initially sensed that there might be parallels between IKEAs masterfully crafted product delivery model and that of software development. However, too much customization has its own considerations and challenges. Some of these factors would be negative, considering who would be the constructor (the average person, who would have limited construction ability). So, the IKEA furniture is not so customizable to the point where it is too complicated for anybody to figure out - not so customizable that one could mess up too terribly. The idea is that anyone could construct the furniture.

To the point of software engineering: what IKEA has successfully done with furniture is what software engineers aim to do with web applications in software development - be it developing objects, pages, templates, widgets, functions, components for fully custom built applications, CMS, or CRM. What developers strive to do is build the parts and tools for the construction of a website and provide these parts and tools to those who would then use these pieces to build the class, site, or another functional piece. The individuals who use these pieces could be made up of other engineers, editors, or business people, depending on how your team is structured.

Layering the development system in this way has clear benefits in terms of programming, architecture, and design that are immediately beneficial to any business that wishes to deliver web applications. The questions that instantly came to my attention when considering these design genius-level details about IKEA's products are:

For point 3, our ultimate concern - of course there are similarities - you just have to figure out what they are.

Here are a few parallels:

IKEA creates clearly separate pieces that can be re-used across an ecosystem of furniture. An example - IKEA creates a cabinet piece but this piece is built in a specific way. The piece is built in a way that it can be used and combined with other pieces reliably - with minimal to no sacrifice in design and structural quality.

Ensuring there exists a clear set of principles/guidelines to create a sort of standardization and architectural landscape to development and design of what will become part of the product component ecosystem is an important point, and to the point of combining pieces together, there is a need to establish these rules of the game ensuring that your piece can interface correctly with pieces designed by other engineers or developers.

In software development, a definite way that we guarantee that pieces will fit together is by leveraging interfaces. In establishing an interface, you define the inputs, outputs, properties, fields, methods, etc. - the attributes of anything that would by need to be connected with - there is a sort of contract between one component and another component that one component can assume that a part on the other component will exist. For a piece of software this might be a publicly available property or method, and for a piece of furniture this might be a hole or a wooden connector. When you then have an interface, a contract between the components, it can then be said that as long as these terms of the contract are met, the components may connect reliably. Whether it is in IKEA furniture development or software development, this understanding of interfacing and contractual requirements between potentially connectable components is critical to designing interchangeable pieces of a system, be it a piece of software or a chair.

In terms compartmentalization, there is a definite similarity between software development and IKEA furniture development. This ability to interface components in the physical world, a more restrictive an environment than the virtual world, to facilitate customization for the constructor is an admirable outcome that IKEA has created on a mass scale, and again something that software developers strive to create in their own work.

For IKEA, the components must interface in a way that allows for the level of customization demanded by the market, and allows them to connect while maintaining the integrity of the system. The integrity of the system in the case of furniture would be: being able to hold things up, contain things, open and close - all of the basic functionality you would expect out of a piece of furniture. For software, the integrity of a system would be: does the key functionality of this work, is the intended resulting functionality of interfacing these two components working as intended, does the system run without crashing, and so on.

In software development, styling a huge factor, and so you must have your styling development and implementation model as effective and customizable as possible. Designers of a website craft the look and feel of their website in highly specific and deliberate ways - ways that purposely control the way a business' brand is perceived. Because of this, you must be prepared to enable your manager of your website to be able to customize the styling details of their website by exposing appropriate variables of the website such as logos, theme colors, secondary colors, etc.

One property that makes web development unique from furniture construction is that in web development, developers are affored the benefits of what are known as cascading styles. What the use of cascading styles means is that if a page is developed correctly, the theming of a site and its pages are deferred to specific types of styling files that are specialized to control theming of the site in a scalable and maintainable manner. However so, there are still analogs between furniture development and software engineering.

In furniture development, the customer is able to choose and customize what kind of color, and therefore look and feel of a piece of furniture, at least to an extent. Even width, height, and depth of certain pieces can be customized. In cases of customizing dimensions of a piece of furniture, what IKEA provides is basically the same piece of furniture, but in a different size and a different object. Similarly, in software development, it is possible to customize these properties of a piece of the system, however in the case of software, the component itself is modified rather than creating a copy of the object with certain properties kept the same as the already existing object and some properties altered. Obviously in the physical world, you cannot easily take the same component and change the size on-demand, like you can in a software application, but you have that same sort of option, where you have a set of preset sizes and you can choose between them as a person who wishes to customize according to their style preferences or tastes.

In software, there are multiple ways of looking at engineering a system. A perspective that I have found useful in architecting solutions for clients over the past 7 years is keeping in mind that a clear and definite goal of software development is that we as software engineers are responsible for defining the controls to manipulate what is ultimately data. As the software interfaces in large part visually based beings (accessibility in software applications is nowadays more of a consideration however), it becomes important to intentionally design the visual representation of this data in an accurate and useful way. Having a team or individual (in IKEA's case the customer) as a decision maker on the construction and styling of the end result is key component that makes styling in IKEA's product delivery model exemplary.

In IKEA furniture development, there is a problem. The problem that IKEA faces is that the pieces of the furniture must be able to be constructed in a nearly intuitive way. The job of the person developing the pieces is to develop the pieces in order to set up the constructor for success. One way that he does this is by making the components easy to use. IKEA recognizes that certain parts could be more difficult to use, so they wish to identify the parts of construction are going to be too difficult to construct, considering and knowing their constructors, and decide which parts of development to keep outside of the constructors hands.

Goals I have when architecting a solution with customization at the construction layer in mind:

The above are important considerations for anyone who is looking to create optimal customization for their product. The key is that in development, we actually think about the other teams involved.

IKEA product developers create their pieces with constructor success in mind by considering the process of construction - that is the steps and phases of construction. In cases where pieces must be kept separately, and therefore handled during the construction phase, rather than asking "is a combination of pieces is too difficult to construct", what is asked is "is this process of putting the pieces together too difficult considering our constructors skillset and tools". Then the question becomes "what kind of tools can we provide to facilitate construction". The step of asking what tools can development provide to facilitate construction is a step that must be taken in both software production and furniture component production.

Recently, upon constructing a piece of furniture from IKEA, I had noticed particular difficulty in a step of the construction process. The construction process required that eight rods be aligned in a precise way to interface with another piece. All pieces being uncontrollable simultaneously, certainly not to the point where I would be able to align them to fit in with another heavy piece, I consulted the instructions. Genius - they had included a lightweight piece of cardboard whose sole function was to aid in the alignment process. By having this supplementary piece, responsibility of aligning the pieces is then shifted from the heavy piece to a smaller, more manageable and specialized alignment tool.

As engineers and business analysts, we have to keep this in mind as well - additions to the dev process to increase likelihood of success during construction. This piece that had been introduced to the construction process firstly made a process that might require greater expertise into a more manageable task, while secondly greatly reduced the chance of error in the construction process no matter the constructor.

In order to make this sort of analysis, you must have understanding and at least a sense of the perspective of all parties involved. You must have both an engineering and technical ability, as well as a business sense. More specifically, In the case of IKEA this becomes understanding customer needs, while in the case of both IKEA and software development this means understanding constructor needs. The design teams in both cases must have a clear understanding of both sides - all sides. The core similarity between IKEA as a business and any software development business is that you have one group that produces products for others to produce another ultimate result, and in order to make decisions that affect both groups, you must have a an understanding of each team and their responsibilities.

As a leader for my team, I am always looking for even better ways to explain tough technical concepts to business teams, as well as present complicated business concepts to multi-functional and highly-skilled technical teams. The best way I have found to do this so far is to relate what is more commonly known to what someone is seeking to understand. Hopefully for those of you who have been through the process of IKEA furniture development now have a greater understanding of software development practices! For those of us with software engineering expertise, there is certainly a lot we can learn from IKEA.