We’ll Always Have Paris
A snowstorm was in the forecast so my youngest daughter Sophia and I went to our local Wal-mart to replenish the essentials: bread, milk, and self-esteem. Since we’d probably be cooped-up in the house for a few days, Sophia suggested we do a jigsaw puzzle together. It sounded like a good way to pass the time and do some father/daughter bonding together, so we headed to the toy department and selected a 1000-piece puzzle of a painting of classic Paris.
If you’ve ever done a jigsaw puzzle, you know a 1000-piece jigsaw puzzle is around 999 pieces too many. So, like any lazy man would do, the first thing I did when we got home was I opened Google and typed, “The Easiest Way to Solve a Jigsaw Puzzle.” To my surprise, pages of results filled my screen; however, I was too lazy to view more than a few so I visited the first three or four sites that explained the same basic process for solving the puzzle the quickest way:
- Study the picture on the box to get a clear understanding of what you’re building
- Dump all of the pieces onto a work area and turn them face-up
- Sort the pieces into various piles containing the edge pieces and pieces of similar colors
- Assemble the edge pieces first to establish the boundaries.
- Assemble the larger objects in the picture, or “sub-assemblies” individually
- Move the sub-assemblies into their general location within the boundary
- Fill in the remaining pieces to connect the sub-assemblies
- Drink a beer (I added that one)
After reading the instructions, I dumped the box onto the kitchen table, saw the overwhelming mound of pieces, then jumped directly to step #8, which ultimately resulted in being without a kitchen table for over a month. However, Thanksgiving Day was rapidly approaching and we needed to kick our jigsaw production into high gear so we could actually eat at our family table.
We studied the picture on the box, then flipped the pieces over one-by-one while simultaneously sorting them into their respective piles. We also picked through each pile to find any pieces with lettering or words on them, such as street signs, addresses on buildings, the artist’s signature, etc. Aside from the edge pieces, these are the easiest to identify and assemble.
We assembled our boundary with the edge pieces, then quickly assembled all of the signs and things with lettering. Easy money. Then, we did the “divide and conquer method” where I worked on the Eiffel Tower and Sophia worked on the Moulin Rouge sub-assemblies. My son Connor even jumped in to work on the hot air balloon. These were all different colors, sorted into different piles and we could work independently of each other while still working to accomplish the same goal.
Finally, we moved the large sub-assemblies into place and filled-in the remainder of the pieces to connect them together. The sky in the picture actually took the longest – probably because all of the pieces were the same, plain color. Boring. If you get stuck here, go directly to step #8 and call it good.
Solving the AEM Jigsaw Puzzle
If you approach your AEM project like a jigsaw puzzle, you can gain efficiencies by following the same basic steps as above.
- Study the picture on the box to get a clear understanding of what you’re building – Study all of the creative, wireframes, business and functional requirements documents and matrices to have a clear understanding of what you’re ultimately creating. If your client is doing an entire digital transformation of multiple properties but starting with one site as a ‘pilot’, it’s important to consider the components, templates, and services of the other web properties to promote true reuse (and less work for you). Adding flexibility to accommodate for future state reduces development time, the number of templates and components, and regression testing effort in the future. Always consider the future state.
“We were recently engaged to consult on the first phase of a multi-site migration. Phase one consisted of only one of the client’s many web properties. The client considered this their ‘pilot’ site that would be a proof-of-concept for future roll-outs of other brands under their umbrella. There was a larger corporate-wide decision to use AEM as the enterprise-wide WCXM platform; however, there was a great disconnect between the individual brand managers who were approached the migration of their brand sites as separate projects entirely. So, separate RFP’s went out to agencies to bid on the work individually and the intercommunication between the brands and IT to standardize on the approach was non-existent at best. So, each RFP response was estimated ‘from scratch’ without any consideration of creating a library of common, reusable templates, etc. I evaluated the other properties to find commonalities and opportunities for standardization resulting in a potential (and realistic) savings of almost 20-30% on subsequent roll-outs by reusing the components, templates, and services. By evaluating and designing for the other web properties first and understanding the ‘big picture’, the pilot site set the groundwork for establishing a true, enterprise-wide system and standard for the subsequent brands to use and follow.”
- Dump all of the pieces onto a work area and turn them face-up – This is the favorite part of the project for any true nerd (myself included) – that is, the technical discovery process to understand what systems, integration points, and other Adobe products that you’ll be working with. This discovery could take the form of stakeholder interviews or Technical Audit sessions where you uncover all of the existing technology collateral and web properties to determine what’s staying and what’s going away. Ultimately, these pieces will all be connected in the finished product, but it’s this discovery process that gets the technical architect warm and fuzzy. Your organization should have a technical audit template or discussion guide to use as a basis for the interviews. I prefer to send the document template to the client before the formal interviews for them to complete as much of it as possible (and to ensure the right people are in the room to answer the questions). Then, it becomes more of a review of their technology landscape as opposed to an interrogation. Sections in your technology audit document should include:
- Platform information for each web property (CMSs, client-side frameworks)
- Data store requirements and connectivity
- Web services integration
- VPN or IP Whitelisting requirements
- Application and web server configurations
- Source code repositories
- Security and performance testing integration
- Coding standards
- Analytics platforms
- Mobile support
- User-generated content (UGC)
- Single Sign-On integration
- Social channel integration
- CRM integrations
- Mapping/Geo-location services
- Accessibility requirements
- Third-party services or vendors
- Sort the pieces into various piles containing the edge pieces and pieces of similar colors – At this stage of the project you identify and document the templates, components, and service integration points to build. You should already have a good idea of the parts you’ll be building if you did a good and granular job of estimating your project in the first place and had a successful technical audit. Having self-contained blocks of functionality allows you to divvy the work across your development team when development begins. This organization exercise will also help identify commonalities to define a component inheritance model, meaning, establishing base functionality of common components and extending them when the functionality of a component deviates from its parent. The correct place to document this is in your Technical Design Document (or Specification). Again, I’m not a fan of old school printed documents, so I use Google Docs or a wiki to author this specification. For a more Agile approach, define your components in Jira or a Trello board. Other self-contained pieces include custom widgets and xtypes, custom replication or flush agents, roll-out configurations, site search collections, workflow models, processes and launchers, and campaign and segment definitions for personalization.
“Sometimes when you start a jigsaw puzzle, you find pieces that are already attached. You may even get lucky and have four or five pieces already connected together. You could break these apart and reconnect them, but why? It’s already done for you! The same thing happens in a project. There are legacy features and functionality that already exist that someone will want to rewrite for the sake of rewriting, just to have it all in the WCXM system. An example of this is user generated content such as comments, ratings, and reviews of product data. Why reinvent the wheel and recreate that functionality when you can simply find a way to leverage it in its existing state? Rather, spend time fortifying the ability to retrieve and store that data in its existing state.” – Me
- Assemble the edge pieces first to establish the boundaries – In this case, the “boundaries” are defined as the templates, scaffolding, site and URL structure, navigation components that you’ll ultimately use to build out the pages and content. In my story above, I also mentioned assembling pieces with words or lettering on them. These equate to simple, content-managed components where an author enter values to input fields to create content. You should build these components before any other components. In my previous article “Develop your AEM Project in this Order“, I explain this approach and the importance of this order in more detail. Check it out.
- Assemble the larger objects in the picture, or “sub-assemblies” individually – If you were successful in defining self-contained pieces of functionality in your Technical Design Document, these can now be developed independently of other development efforts. Examples of “large”, self-contained pieces of functionality are booking and reservation web services, login and registration features, or anything else that the primary function of the site is dependent upon. Prioritize these at the beginning of the project by their complexity and true importance to launch. These are the critical features of the site that must be completed in phase one. Of course, you’ll tell the client they’ll get all of it when the site launches, but let’s be completely honest. There are always features that get pushed to a ‘phase two’ because they were either underestimated, managed poorly, pushed aside, had the wrong developer assigned to the work, or just weren’t production ready. Now, if you had to decide between launching a hotel site with the ability to find a room with a booking search service or the ability to watch a 30-second video of the hotel in a custom video player (when the standard video player would work), which would you/the client rather have at launch? Exactly.
“First get the car running, then you can wax it.” – Me
- Fill in the remaining pieces to connect the sub-assemblies – These are the finishing touches on the site. The tedious ‘sky’ pieces in my puzzle story equate to the little CSS/style tweaks you do to get it all ‘pixel perfect’. First impressions are lasting impressions, so give your team time to make these final touches so a customer’s first visit to the site is memorable.
- Drink a beer – To celebrate your success with your team, not to drown your sorrows in booze.
Here is our finished product which is now framed an hanging on Sophia’s wall. In total, the puzzle took us over a month to complete. But the conversations and laughs we shared at this table will be remembered forever. Au revoir!