Creating new developer ecosystems: The Adobe Architecture as a Case

To make the big bucks in software development you need to create developer cultures. “Developer culture” can synonymously be phrased as a “developer ecosystem.” Either way, the idea is that a “developer culture” encompasses:

• A shared understanding of the problem(s) being solved
• A shared understanding of the general solutions to those problems
• The methods those solutions are applied to the problems, the means of solving the problems
• And, often, a method for evolving and adapting the community to new problems

Oftentimes, esp. in The Days of Old, specific technology was shared, but that’s not always the base now-a-days outside of Elder Company ecosystems (e.g., Microsoft, IBM, and others who have long standing developer cultures).

Building a Developer Ecosystems: Adobe

I’ve been observing Adobe spinning up a developer ecosystem around in the enterprisey neighborhood for the past year or so. As a client, we do consulting from time-to-time with Adobe, of course, most recently when it comes to open source. They provide and interesting case, currently in evolution, for thinking about growing developer cultures and ecosystems.

In the case of Adobe, through M&A lead architecture Russian-dolling that’s in vouge now-a-days, they’re starting from a common position. Adobe has a stable of independently viable and technologically fitted ecosystems that they’re trying to pull together into one uber-ecosystem. Essentially, you have Macromedia (Flex/”Apollo” and ColdFusion) and Adobe (PDF, LiveCycle, and Creative tools like PhotoShop and Illustrator).

Integration

Since Adobe acquired Macromedia in Dec. 2005 (it’s easy to forget how recent that was) there’s been work to integrate the stacks together, if only in a sort of loosely coupled fashion. There’s still some architectural integration the table when it comes to cobbling together the Flex/”Apollo”, ColdFusion, LiveCycle, and document lines into something that could be compelling called The Adobe Architecture.

You can get those enterprisey feel-goods from things and companies like LAMP, BEA, IBM, and open source, Java/JEE de facto stacks. In the case of Adobe, though the pieces seem to be there, the stack-story is still largely a front-end one with loose connections to document management and graphics production. While there’s glue-layers, like LiveCycle Data Services (formally Flex Data Services) to feed the front-end, there isn’t that same, widely-felt feel of enterprise architecture matureness, for example the one you can easily scoop up in the JEE world.

The Desire

It’s clear to me that Adobe wants to pursue more than just a solid home-stead on the front-end of software development, enterprise or no. The LiveCycle brand has been gobbling up back-endy technologies like Flex Data Services, and much of the discussions we’ve had in public and private with Adobe have centered around moving them further into the enterprise space, down the layer-stack.

The Technical Architecture: Full Stack of Components?

Looking at Adobe’s portfolio technologically, the key items missing are back-end components like applications servers, databases, buses, and other infrastructure gorp. On the one hand, I can poke at Adobe for missing these things. While on the other hand, I could say that maybe the point is to provide components that fit into whatever back-end gorp a given customer wants to use. Indeed, this second hand is what I was getting at with:

My sense is that Adobe’s stable of back-end technologies and layers now work together, but that there could be more consolidation among them, if only conceptually,” he said. “Adobe seems to be favoring a component-based back end, where developers choose which application server to run Adobe components in rather than using whatever run-time Adobe may choose as The One True Back End. I feel like this consolidation strategy could actually work in Adobe’s favor as their strengths are closer to the front-end layers rather than the back-end layers.

I often lambast companies for having “suite dreams” where-in any given vendor has a complete solution UI to middleware to database to even hardware. The point of that lambasting is that these systems are prone to be less flexible and extensible in the long-term as business needs evolve and the IT must change. What a suite dream gives a vendor and that vendor’s users though, is a detailed plan and approach for doing something. It gives those two parties a development culture based on technology that answers how things get done, which can be extremely beneficial in the short term, and even the long term if that culture changes rapidly enough. Often, the second doesn’t hold, leading the rip-and-replace suite dreams: both vendors and developers have a (bad?) habit of leaping from the old to the new suite dream instead of shoring up and evolving existing ones.

Dreamless Architectures

When you lack a suite dream, you need a more conceptual, rather than technological, basis for the development culture. To a large degree, “web programming” is a conceptual-based rather than technologically based development culture. While there are several constants-by-volume like Apache HTTPD and inescapable (though easily abused) standards like URI’s, the technology driving web development culture is varied and ever changing.

Tthe pillars of web development are largely cultural:

• Schools of thought like REST have codify the conceptual basis of the web development culture
• We easily forget the web standards cultural wars of the late 90’s and early 00’s
• More recently, Ajax and OpenID are each examples of a development culture lead more by concepts, conventions, and very informal, even ad hoc standards than any given technology

Creating the ecosystem and market

If Adobe isn’t going to provide and maintain a complete stack up and down — a “suite dream” — it too needs a codified conceptual basis for it’s development culture. (There’s always allegiance to an existing culture, but Adobe seems to want something new, if even “evolved.”)

Otherwise, Adobe technologies and Adobe itself will be relegated to where it is now: the front-end, graphics, and document production and management. Once this architecture is laid out, Adobe can create the desire and need for developers to pull more and more Adobe technologies into their stacks rather than just picking out the tasty front-end technologies from the Adobe buffet. A large, flourishing ecosystem is better than a collection of independent ecosystems [this no doubt a point of contention].

As ever in the contemporary world of commercial software, creating and maintaining the market to collect your revenue from involves coming up with an ecosystem, often interlaced with open source. Indeed, with the conceptual ground work — the architecture laid out — you could see how Adobe could also start using open source to fill in the blanks in the system layers, even customizing and fitting those infrastructure bits to the Adobe architecture.

The goal of all this is a widened, if not new ecosystem of developers whose belief and allegiance to that culture’s understanding and methods of software development can be relied on to (a.) provide a methodology of developing software, (b.) provide a self-sustaining, long-lived ecosystem, that, (c.) creates a market for Adobe and others can sell to. The last point is what gets in people’s craws, of course, and involves much careful “community management” to balance vampiric vendor desires with do do-no-evil pony-tudes.

What would these shared concepts and the resulting developer culture be? Well, that’s the real work, isn’t it? I suspect they’ll be something like SOA, Web 2.0, highly web-aware applications, documents-centric workflows, and a re-instatement of beautiful and effortless user-interaction over all else, the last of which Apple’s been madly successful with of late.

A Technology-lead Culture: rails

To contrast the discussion above, I’d suggest that rails is a technology driven developer community. There are certainly core concepts at the community now — James’ rails-crush, the notion of “convention,” for example. But the actual technologies involved are inescapable: there aren’t “rails implementations” in the same way there are “JEE implementations. While there are rails ports, like grails, but that feels somewhat different than WebLogic, JBoss, WebSphere, Glassfish, etc. as JEE implementations

The General Application

While the meat of the above is centered on Adobe, the general ideas are applicable to would be ecosystem builders in general. You either need a technology to build your developer culture around or shared concepts. You can always take the “both” option on this, but my sense is that the best risk/reward strategy is to start with one, and add on the other as called for: in Adobe’s case, laying out the shared concepts and then fitting in the technology, in rails’ case, starting with the technology and then reverse engineering the concepts.

Disclaimer: Adobe, IBM, Sun, and parts of Microsoft are clients.

Technorati Tags: adobe, apollo, coldfusion, culture, ecosystems, flex, jee, livecycle, ria, soa