Tag Archives: modularity

Modularity without modules…what’s the point?

If you follow me on Twitter, you might have an idea that my son is currently without one of his rides (i.e. a Razor Cruiser kick scooter). My son is big and tall for his age, and this scooter is perfect for him.

Like most boys his age, though, he doesn’t understand “cruiser” in the face of a neighborhood of boys who all like to jump all manner of wheeled vehicle. :-) As a result of this lack of appreciation (er, love of both scooter and jumping), what looked like

Unridden Razor Cruiser kick scooter

now looks like

Used Razor Cruiser kick scooter front assembly

Failed wood/fiberglass Razor Cruiser kick scooter deck

Failed wood/fiberglass Razor Cruiser kick scooter deck (close-up)

Used Razor Cruiser kick scooter back assembly

Do you see the opportunity?

Razor makes a quality product–one the is easy to use and maintain. Ease of maintenance is largely facilitated by modularity of design.

So when my son came to me with the disappointment of pushing his ride too hard, my first thought was to simply disassemble the scooter to isolate the failed part (deck). Easily accomplished.

Except that apparently Razor and its authorized parts retailers doesn’t stock replacement decks for the Cruiser kick scooter.

So…Razor built a modular kick scooter but doesn’t stock a critical module (deck).

What’s the point of modularity, if there are no modules (i.e. ability to swap module instances that fulfill necessary interfaces)?

My son’s predicament is clearly of his own making, but herein is opportunity for Razor. Beyond already clearly stating what their product is designed to perform, Razor can anticipate that boys will be boys and provide timely relief in the form of complete replacement parts, including readily available decks.

Within earshot of my son are more than a dozen boys of similar age, and they’re always outside planning their next jump. Many already own their own Razor, too. What if he could turn around an accident with word that Razor saved the day? Talk about brand advocacy and social media!

What’s your Razor-like story? What’s your Razor-like opportunity?

Modularity is critical to industrialize differentiated experience

Modularity is perhaps the most essential architecture principle applied across the Adobe® Digital Enterprise Platform (ADEP). Modularization in ADEP enables you to manage the complexity of your CEM solutions by separating them into independent components and other concerns that can be worked on by different development teams and tested in isolation. When deployed, these solutions consume minimal footprint that is associated with specific workload requirements (i.e. resource usage is kept to what is essential for delivering business value).

Modularity

The very nature of differentiated customer experience is modular–my experience today should differ from my experience tomorrow, from my experience yesterday and from what another customer may experience. ADEP anticipates, is tuned for and can accelerate composition and reuse. In an enterprise context, supporting such modularity means that you can draw upon the breadth of assets (content, applications, documents, processes, services) available, including those from Adobe, Adobe’s partners, systems integrators, agencies and other teams within your enterprise. These assets can be brought to bear on business problems in a manner that can be partitioned and rolled out incrementally with minimal disruption (e.g. hot deployment[1]).

Modularity in ADEP is a form of separation of concerns that provides both logical and physical encapsulation of classes. Modularity is desirable because it allows you to break applications into logically independent pieces that can be independently changed and reasoned about. Modularity enables division of labor across a solution, and it promotes abstraction, reuse and ease of maintenance and repair.

As a consequence of embracing modularity as a core architecture principle, software modules in ADEP are self-contained (local wholes), highly cohesive (fulfill single purposes) and loosely coupled (well-isolated from other modules).

To support all three properties, it is vital for modules to have a well-defined interface for interaction with other modules. A stable interface enforces logical boundaries between modules and prevents access to internal implementation details. Ideally, the interface should be defined in terms of what each module offers to other modules, and what each module requires from other modules.

Modularity is driven across the ADEP architecture via the following principles:

  • Interface-based programming[2]
  • Externalization of cross-cutting concerns (aspect-oriented programming[3])
  • Late binding of implementation instances to interfaces (dependency injection;[4] extensibility)

Next: everything is content.

Update 9/6/2011: The larger technical white paper from which this post was drawn is now available from the ADEP Developer Center as a PDF download. Please feel free to provide me with your feedback on that work here. Thanks in advance!

Footnotes:
[1] i.e. a provision of dynamic modularity in an OSGi-based system like ADEP
[2] Please consider Interface Oriented Design for a more detailed discussion of interface-based programming.
[3] Please consider AspectJ in Action: Enterprise AOP with Spring Applications, Second Edition for a more detailed discussion of aspect-oriented programming (AOP).
[4] Please consider Dependency Injection: Design patterns using Spring and Guice for a more detailed discussion of dependency injection (DI).