PED: A BRIEF RETROSPECTIVE
In 2002, Java was adopted as the standard platform for in-house development at a successful large automotive manufacturing enterprise (“the Company”). In the ensuing years, many applications would migrate to Java. Marvin Toll consulted with one such co-located project team in 2004 to migrate a significant global dealer application to the new platform.
Despite a deep understanding of the business domain, the team was about to take on a technical challenge without the correct skill set! A tight project timeline precluding formal Java language training compounded the skills deficit. Fortunately, the team included capable performers that worked well together.
In 2004, we asked: Could a novel approach compensate for the lack of requisite Java knowledge? Would the project succeed if the team committed to adopting simple patterns prior to coding? If so, which ones? Would single-class example pattern implementations, or snippets, be effective for communicating to an audience without a Java background? How much Test Driven Development (TDD) could a team absorb when they had not learned the programming language?
A significant portion of the project’s success can be traced to what would years later be codified as Pattern Enabled Development® (PED). As Todd Hall, technical lead and architect, reflects: “without patterns, the team would not have created a solution or an application architecture that is still in use ten years later.” Thus launched the PED Journey, a decade-long validation and refinement of lessons first learned from a single project team, and the pursuit of several additional thought-starters:
2005 – Would a monolithic abstraction (framework) wrapping primary technologies (in this case, both Struts and Toplink) be beneficial? (Although we tried this option with several teams, we concluded that a monolithic approach was a failed strategy. This initiative was abandoned in favor of a revised approach in 2007.)
2006 – Would a reference application based on existing production use cases serve to connect the efforts of multiple globally distributed teams? (We soon realized the complexity of ‘real world’ use cases was inhibiting the learning of fundamentals. This initiative was abandoned in favor of simpler use cases in 2008.)
2007 – Could loosely-coupled Adaptable Technology Wrappers (ATWs) of Open Source Software provide development convenience and insulate “the Company” from external API changes? (We later wondered if an ATW could foster enterprise alignment with a Pattern Language?)
2008 – Could a Reference Application supersede comprehensive documentation as the primary vehicle for providing architectural and design guidance? (We later pursued using the Reference Application as a tool for fostering enterprise alignment with our Unified Pattern Language.)
2009 – Could Instructor Guided Training inspire use of the reference application as a self-study resource for software engineering?
2010 – Would providing a website featuring a Unified Pattern Language encourage project teams to derive their own Pattern Palette?”
2011 – Could we use functionally equivalent services to speed test execution while reducing a dependence upon mock-related objects? (See JUnit Strategy for Testing
2012 – Could a Palette Analyzer tool provide effective metrics for enhancing code quality? (As of 2017 this idea has not gained traction… perhaps it remains ‘ahead of its time’? Or, it could just be a bad idea.)
2014 – Are there ways to increase the value of our Unified Pattern Language usage for “the Company?” (In 2016 this question was partially answered by reducing the number of core patterns by almost 50%.)
2015 – Could a closer alignment with the Open Source Software community enhance the effectiveness of application development within “the Company?” (This question is currently being pursued with the launch of the Justify Spring initiative.)
2016 – Could the role of JUnit testing be extended to include “forward compatibility” verification? That is, will the production code tested on today’s stack also run on tomorrows emerging stack? (The intent is to extend the life of production code by writing to a durable API . For example, will our REST implementations easily to convert to faster solutions such as WebSockets?)
2017 – What about the cloud? Should we consider The Twelve-Factor Application to be a DevOps marketing gimmick or a legitimate methodology maturation?
 Julie Burnard, Lead Application Architect, Java Center of Excellence (JCOE), November 16, 2011:
Marvin [Toll] has been the strategic force in the JCOE behind the Application Architecture, Core Frameworks [ATW], JAB [Reference Application] and JADAF [Instructor Guided Training] and much more. His passion for technology and belief in doing the right thing are truly inspiring.
 Todd Hall, private correspondence, June 30, 2014.
 Thomas Newman, Java Center of Excellence (JCOE), July 5, 2016:
It is nice to know you are most of the way there before you get hit by the tech refresh bus.